Good numbers. Did you a 2nd rm -rf too? It should show the largest improvement of all.
On Jan 19, 2009, at 4:57 AM, "tristan.ye" <[email protected]> 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 > _______________________________________________ Ocfs2-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-devel
