From: Jeff Moyer <jmoyer@redhat.com>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vladislav Bolkhovitin <vst@vlnb.net>,
Jens Axboe <jens.axboe@oracle.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] readahead: introduce context readahead algorithm
Date: Wed, 15 Apr 2009 13:55:48 -0400 [thread overview]
Message-ID: <x49r5ztg5sr.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <20090415044301.GB9948@localhost> (Wu Fengguang's message of "Wed, 15 Apr 2009 12:43:01 +0800")
Hi, Fengguang,
Wu Fengguang <fengguang.wu@intel.com> writes:
>> I tested out your patches. Below are some basic iozone numbers for a
>> single NFS client reading a file. The iozone command line is:
>>
>> iozone -s 2000000 -r 64 -f /mnt/test/testfile -i 1 -w
>
> Jeff, thank you very much for the testing out!
>
>> The file system is unmounted after each run to flush the cache. The
>> numbers below reflect only a single run each. The file system was also
>> unmounted on the NFS client after each run.
>>
>> KEY
>> ---
>> vanilla: 2.6.30-rc1
>> readahead: 2.6.30-rc1 + your 10 readahead patches
>> context readahead: 2.6.30-rc1 + your 10 readahead patches + the 3
>> context readahead patches.
>> nfsd's: number of NFSD threads on the server
>
> I guess you are applying the readahead patches to the server side?
That's right.
> What's the NFS mount options and client/server side readahead size?
> The context readahead is pretty sensible to these parameters.
Default options everywhere.
>> I'll note that the cfq in 2.6.30-rc1 is crippled, and that Jens has a
>> patch posted that makes the numbers look at least a little better, but
>> that's immaterial to this discussion, I think.
>>
>> vanilla
>>
>> nfsd's | 1 | 2 | 4 | 8
>> --------+---------------+-------+------
>> cfq | 43127 | 22354 | 20858 | 21179
>> deadline| 43732 | 68059 | 76659 | 83231
>>
>> readahead
>>
>> nfsd's | 1 | 2 | 4 | 8
>> --------+---------------+-------+------
>> cfq | 42471 | 21913 | 21252 | 20979
>> deadline| 42801 | 70158 | 82068 | 82406
>>
>> context readahead
>>
>> nfsd's | 1 | 2 | 4 | 8
>> --------+---------------+-------+------
>> cfq | 42827 | 21882 | 20678 | 21508
>> deadline| 43040 | 71173 | 82407 | 86583
>
> Let me transform them into relative numbers:
>
> A B C A..B A..C
> cfq-1 43127 42471 42827 -1.5% -0.7%
> cfq-2 22354 21913 21882 -2.0% -2.1%
> cfq-4 20858 21252 20678 +1.9% -0.9%
> cfq-8 21179 20979 21508 -0.9% +1.6%
>
> deadline-1 43732 42801 43040 -2.1% -1.6%
> deadline-2 68059 70158 71173 +3.1% +4.6%
> deadline-4 76659 82068 82407 +7.1% +7.5%
> deadline-8 83231 82406 86583 -1.0% +4.0%
>
> Summaries:
> 1) the overall numbers are slightly negative for CFQ and looks better
> with deadline.
The variance is probably 1-2%. I'll try to quantify that for you.
> Anyway we have the io context problem for CFQ. And I'm planning to
> dive into the CFQ code and your patch on that :-)
Jens already reworked the patch and included it in his for-linus branch
of the block tree. So, you can start there. ;-)
> 2) the single thread case performance consistently dropped by 1-2%.
> It seems not related to the behavior changes introduced by the mmap
> readahead patches and context readahead patches. And looks more like
> some overheads created by the code reorganization and the patch
> "readahead: apply max_sane_readahead() limit in ondemand_readahead()"
> which adds a bit overhead with the call max_sane_readahead().
>
> I'll try to root cause it.
>
> Thanks again for the numbers!
No problem.
Cheers,
Jeff
next prev parent reply other threads:[~2009-04-15 17:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-12 7:19 [PATCH 0/3] context readahead for concurrent IO take 2 Wu Fengguang
2009-04-12 7:19 ` [PATCH 1/3] radix-tree: add radix_tree_prev_hole() Wu Fengguang
2009-04-12 17:29 ` Andrew Morton
2009-04-13 13:44 ` Wu Fengguang
2009-04-12 7:19 ` [PATCH 2/3] readahead: move the random read case to bottom Wu Fengguang
2009-04-12 7:19 ` [PATCH 3/3] readahead: introduce context readahead algorithm Wu Fengguang
2009-04-12 8:48 ` Ingo Molnar
2009-04-12 12:35 ` Wu Fengguang
2009-04-16 17:12 ` Vladislav Bolkhovitin
2009-04-15 3:43 ` Jeff Moyer
2009-04-15 4:43 ` Wu Fengguang
2009-04-15 17:55 ` Jeff Moyer [this message]
2009-04-27 4:48 ` Wu Fengguang
-- strict thread matches above, loose matches on Subject: below --
2009-04-10 13:12 [PATCH 0/3] context readahead for concurrent IO Wu Fengguang
2009-04-10 13:12 ` [PATCH 3/3] readahead: introduce context readahead algorithm Wu Fengguang
2009-04-11 0:16 ` Andrew Morton
2009-04-12 7:11 ` Wu Fengguang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x49r5ztg5sr.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vst@vlnb.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®