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: <CANejiEW3hmQJ4WUTkfJ+p+4Wg1Vgp8cHmTOTs1uGMLRae72M7w@mail.gmail.com>
Date:	Wed, 27 Jul 2011 11:09:58 +0800
From:	Shaohua Li <shli@...nel.org>
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

2011/7/24 Jens Axboe <jaxboe@...ionio.com>:
> On 2011-07-22 07:14, Shaohua Li wrote:
>> 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.
>
> That's a good win right there, imho.
>
>> how to check the cycles spend submitting the I/O?
>
> It's not easy, normal profiles is pretty much the only thing to go by.
>
> I guess I'm just a bit puzzled by Minchan's reluctance towards the
> patch, it seems like mostly goodness to me.
akpm,
would you consider picking this up?

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/