[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