[Ocfs2-devel] [PATCH 0/3] ocfs2: Inode Allocation Strategy Improvement.v2

tristan.ye tristan.ye at oracle.com
Mon Jan 19 18:34:49 PST 2009


On Mon, 2009-01-19 at 10:35 -0800, Sunil Mushran wrote:
> Good numbers. Did you a 2nd rm -rf too? It should show the largest  
> improvement of all.

Yes, fairly cool, we also got up to 3 mins performance gain during 2nd
rm -rf test:

=============== Tests with 10 times iteration================
 2nd 'rm -rf' result:

Average real time with 10 times: 
Original kernel                            kernel with enhanced patches
 4m3.425ss                                      0m59.423ss




Regards,
Tristan

> 
> On Jan 19, 2009, at 4:57 AM, "tristan.ye" <tristan.ye at oracle.com> wrote:
> 
> > On Mon, 2009-01-19 at 15:15 +0800, Tao Ma wrote:
> >>
> >> tristan.ye wrote:
> >>> On Sun, 2009-01-18 at 07:17 -0800, Sunil Mushran wrote:
> >>>> How big is this disk? Maybe one kernel tree untar is not be  
> >>>> enough to
> >>>> expose the original issue. Also, use ls -i and/or debugfs to see if
> >>>> the inodes have some locality.
> >>>
> >>> Tao, sunil
> >>>
> >>> I've tested it out with more attempts, it may have something to do  
> >>> with
> >>> the disk size. but the root pause why i did not get a excited  
> >>> speed-up
> >>> performance gain was due to the iscsi-target(iscsi server) cache.  
> >>> the
> >>> operation in your testcase which was meant for cache dropping is  
> >>> aimed
> >>> at client side(a 'echo 2>/proc/sys/vm/drop_cache' only flush the  
> >>> fs's
> >>> cache for iscsi initor(isci client)).
> >>>
> >>> Tao,
> >>>
> >>> You can verify this by pausing the tests at the right point before  
> >>> we
> >>> start '2rd ls -lR', then flush the iscsi-target's cache by 'service
> >>> iscsi-target restart'(there may be a more graceful way to do  
> >>> this),after
> >>> this done, resume the tests, then you'll find the the realtime it
> >>> consumed will be up to 3 mins around:)
> >> cool, so I am very glad that you got the same result as mine. ;)
> >>>
> >>> Btw, i really saw lots of locality by 'ls -li' for inodes under a  
> >>> same
> >>> dir, take /mnt/ocfs2/linux-2.6.28/include/linux for instance,  
> >>> almost all
> >>> of its inodes are contiguous one by one regarding to its inode  
> >>> number.
> >> yeah, that is the desired behaviour with my 3 patches. :)
> >>
> >> Then do you have any updated test statistics?
> >
> > Tao,
> >
> > With iscsi-target cache flushed everytime before tests getting  
> > started,
> > following is the updated testing result:
> >
> > Testing node:test7
> > Testing volume: iscsi sdd1
> >
> > =============== Tests with 10 times iteration================
> >
> > 1st 'Tar xjvf' result:
> >
> > Average real time with 10 times:
> > Original kernel                            kernel with enhanced  
> > patches
> > 0m 22.468s                                       0m 23.472s
> >
> > 1st 'ls -lR' result:
> > Average real time with 10 times:
> > Original kernel                            kernel with enhanced  
> > patches
> > 0m 30.682s                                        0m 30.414s
> >
> > 1st 'rm -rf' result:
> > Average real time with 10 times:
> > Original kernel                            kernel with enhanced  
> > patches
> > 0m 1m5.715s                                       0m 1m3.835s
> >
> > 2rd 'Tar xjvf' result:
> > Average real time with 10 times:
> > Original kernel                            kernel with enhanced  
> > patches
> > 0m 31.550s                                       0m 28.726s
> >
> > 2rd 'ls -lR' result:
> > Average real time with 10 times:
> > Original kernel                            kernel with enhanced  
> > patches
> >
> > 0m 3m5.772s                                       0m 30.274s
> >
> > ===============Tests end============================
> >
> > Glad to see your guy's patch has greatly improved the performance of
> > inodes traversing:),
> >
> > Unfortunately, the 1st Tar testcase still get a performance
> > penality(around 1s) everytime.
> >
> > I've kept the testing env on test7 for your verification.
> >
> >
> > Regards,
> >
> > Tristan
> >
> >>
> >> Regards,
> >> Tao
> >




More information about the Ocfs2-devel mailing list