linux-kernel - Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS

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: <alpine.LRH.2.02.1608041439420.21662@file01.intranet.prod.int.rdu2.redhat.com>
Date:	Thu, 4 Aug 2016 14:46:07 -0400 (EDT)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	Michal Hocko <mhocko@...nel.org>
cc:	NeilBrown <neilb@...e.com>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
	dm-devel@...hat.com, Mel Gorman <mgorman@...e.de>,
	David Rientjes <rientjes@...gle.com>,
	Ondrej Kozina <okozina@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle
 PF_LESS_THROTTLE tasks



On Wed, 3 Aug 2016, Michal Hocko wrote:

> > > Even mempool allocations shouldn't allow reclaim to
> > > scan pages too quickly even when LRU lists are full of dirty pages. But
> > > as I've said that would restrict the success rates even under light page
> > > cache load. Throttling on the wait_iff_congested should be quite rare.
> > > 
> > > Anyway do you see an excessive throttling with the patch posted
> > > http://lkml.kernel.org/r/20160725192344.GD2166@dhcp22.suse.cz ? Or from
> > 
> > It didn't have much effect.
> > 
> > Since the patch 4e390b2b2f34b8daaabf2df1df0cf8f798b87ddb (revert of the 
> > limitless mempool allocations), swapping to dm-crypt works in the simple 
> > example.
> 
> OK. Do you see any throttling due to wait_iff_congested?

No, but I've seen occasional stalls of mempool allocations in 
throttle_vm_writeout - but the patch that removed throttle_vm_writeout 
didn't improve overall speed, so the stalls were only minor.

> writeback_wait_iff_congested trace point should help here. If not maybe
> we should start with the above patch and see how it works in practise.
> If the there is still an excessive and unexpected throttling then we
> should move on to a more mempool/block layer users specific solution.

Currently, dm-crypt reports the device congested only if the underlying 
block device is congested.

But as others suggested, dm-crypt should report congested status if is 
clogged due to slow encryption progress - and in that case you should not 
throttle mempool allocations (because such throttling would decrease 
encryption speed even more).

Mikulas

> -- 
> Michal Hocko
> SUSE Labs