linux-kernel - Re: [PATCH]vmscan: add block plug for page reclaim

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1311311695.15392.369.camel@sli10-conroe>
Date:	Fri, 22 Jul 2011 13:14:55 +0800
From:	Shaohua Li <shaohua.li@...el.com>
To:	Jens Axboe <jaxboe@...ionio.com>
Cc:	Minchan Kim <minchan.kim@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"mgorman@...e.de" <mgorman@...e.de>, linux-mm <linux-mm@...ck.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH]vmscan: add block plug for page reclaim

On Fri, 2011-07-22 at 03:32 +0800, Jens Axboe wrote:
> 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@...el.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@...el.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.
I can observe the average request size changes. Before the patch, the
average request size is about 90k from iostat (but the variation is
big). With the patch, the request size is about 100k and variation is
small.
how to check the cycles spend submitting the I/O?

Thanks,
Shaohua

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/