:) tristan.ye wrote: > 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" <[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
