linux-kernel - Re: [PATCH 1/3] page-allocator: Under memory pressure, wait on pressure to relieve instead of congestion

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]

Date:	Wed, 10 Mar 2010 13:35:15 +1100
From:	Nick Piggin <npiggin@...e.de>
To:	Mel Gorman <mel@....ul.ie>
Cc:	linux-mm@...ck.org,
	Christian Ehrhardt <ehrhardt@...ux.vnet.ibm.com>,
	Chris Mason <chris.mason@...cle.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] page-allocator: Under memory pressure, wait on
 pressure to relieve instead of congestion

On Tue, Mar 09, 2010 at 05:35:36PM +0000, Mel Gorman wrote:
> On Wed, Mar 10, 2010 at 02:03:32AM +1100, Nick Piggin wrote:
> > I mean the other way around. If that zone's watermarks are not met, then
> > why shouldn't it be woken up by other zones reaching their watermarks.
> > 
> 
> Doing it requires moving to a per-node structure or a global queue. I'd rather
> not add hot lines to the node structure (and the associated lookup cost in
> the free path) if I can help it. A global queue would work on smaller machines
> but I'd be worried about thundering herd problems on larger machines. I know
> congestion_wait is already a global queue but IO is a relatively slow event.
> Potentially the wakeups from this queue are a lot faster.
> 
> Should I just move to a global queue as a starting point and see what
> problems are caused later?

Yes. This should change allocation behaviours less than your patch does
now in the presence of multiple allocatees stuck in the wait with
different preferred zones.

I would worry about thundering herds as a different problem we already
have. And if wakeups are less frequent, then each one is more likely to
cause a thundering herd anyway.


> > Yep. And it doesn't really solve that race either becuase the zone
> > might subsequently go below the watermark.
> > 
> 
> True. In theory, the same sort of races currently apply with
> congestion_wait() but that's just an excuse. There is a strong
> possibility we could behave better with respect to watermarks.

We can probably avoid all races where the process sleeps too long
(ie. misses wakeups). Waking up too early and finding pages already
allocated is harder and probably can't really be solved without all
allocatees checking the waitqueue before taking pages.
--
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/