From: Jens Axboe <jaxboe@fusionio.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: Minchan Kim <minchan.kim@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
"mgorman@suse.de" <mgorman@suse.de>,
linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH]vmscan: add block plug for page reclaim
Date: Thu, 21 Jul 2011 21:32:16 +0200 [thread overview]
Message-ID: <4E287EC0.4030208@fusionio.com> (raw)
In-Reply-To: <1311144559.15392.366.camel@sli10-conroe>
On 2011-07-20 08:49, Shaohua Li wrote:
> On Wed, 2011-07-20 at 14:30 +0800, Minchan Kim wrote:
>> On Wed, Jul 20, 2011 at 3:10 PM, Shaohua Li <shaohua.li@intel.com> wrote:
>>> On Wed, 2011-07-20 at 13:53 +0800, Minchan Kim wrote:
>>>> On Wed, Jul 20, 2011 at 11:53 AM, Shaohua Li <shaohua.li@intel.com> wrote:
>>>>> per-task block plug can reduce block queue lock contention and increase request
>>>>> merge. Currently page reclaim doesn't support it. I originally thought page
>>>>> reclaim doesn't need it, because kswapd thread count is limited and file cache
>>>>> write is done at flusher mostly.
>>>>> When I test a workload with heavy swap in a 4-node machine, each CPU is doing
>>>>> direct page reclaim and swap. This causes block queue lock contention. In my
>>>>> test, without below patch, the CPU utilization is about 2% ~ 7%. With the
>>>>> patch, the CPU utilization is about 1% ~ 3%. Disk throughput isn't changed.
>>>>
>>>> Why doesn't it enhance through?
>>> throughput? The disk isn't that fast. We already can make it run in full
>>
>> Yes. Sorry for the typo.
>>
>>> speed, CPU isn't bottleneck here.
>>
>> But you try to optimize CPU. so your experiment is not good.
> it's not that good, because the disk isn't fast. The swap test is the
> workload with most significant impact I can get.
Let me just interject here that a plug should be fine, from 3.1 we'll
even auto-unplug if a certain depth has been reached. So latency should
not be a worry. Personally I think the patch looks fine, though some
numbers would be interesting to see. Cycles spent submitting the actual
IO, combined with IO statistics what kind of IO patterns were observed
for plain and with patch would be good.
--
Jens Axboe
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-07-21 19:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-20 2:53 [PATCH]vmscan: add block plug for page reclaim Shaohua Li
2011-07-20 5:53 ` Minchan Kim
2011-07-20 6:10 ` Shaohua Li
2011-07-20 6:30 ` Minchan Kim
2011-07-20 6:49 ` Shaohua Li
2011-07-21 19:32 ` Jens Axboe [this message]
2011-07-22 5:14 ` Shaohua Li
2011-07-23 18:49 ` Jens Axboe
2011-07-27 3:09 ` Shaohua Li
2011-07-27 23:45 ` Andrew Morton
2011-07-28 1:04 ` Shaohua Li
2011-07-28 1:15 ` Andrew Morton
2011-07-28 1:34 ` Shaohua Li
2011-07-29 8:38 ` Minchan Kim
2011-07-29 10:30 ` Shaohua Li
2011-07-29 10:43 ` Dave Chinner
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=4E287EC0.4030208@fusionio.com \
--to=jaxboe@fusionio.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=minchan.kim@gmail.com \
--cc=shaohua.li@intel.com \
/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;
as well as URLs for NNTP newsgroup(s).