linux-kernel - Re: [RFC] : mm : / Patch / code : Suggestion :snip kswapd &get_page_from_freelist() : No more no page failures. (WHY????)

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] [day] [month] [year] [list]

Date:	Wed, 29 Aug 2007 10:14:11 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Mitchell Erblich <erblichs@...thlink.net>
CC:	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>, mingo@...e.hu,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC] : mm : / Patch / code : Suggestion :snip kswapd &get_page_from_freelist()
 : No more no page failures. (WHY????)

Mitchell Erblich wrote:
> Nick Piggin wrote:

> --------
> Nick Piggin, et al,
> 
>     First diffs would generate alot of noise, since I rip and insert
>     alot of code based on whether I think the code is REALLY
>     needed for MY TEST environment. These suggestions are
>     basicly minimal merge suggestions between my
>     development envir and the public Linux tree.

That's OK. So long as the patch is against a well known tree, it
is just less ambiguous even if it doesn't actually compile :)


> 
>     Now the why for this SUGGESTION/PATCH...
> 
> 
>>When we're in the (min,low) watermark range, we'll wake up kswapd
>>_before_ allocating anything, so what is better about the change to
>>wake up kswapd after allocating? Can you perhaps come up with an
>>example situation also to make this more clear?
> 
> 
> Answer
>     Will GFP_ATOMIC alloc be failing at that point? If yes, then why
>     not allow kswapd attempt to prevent this condition from occuring?
>     The existing code reads that the first call to get_page_from_freelist()
>     has returned no page. Now you are going to start up something that
>     is at best going to take millisecs to start helping out. Won't it first
>     grab some pages to do its work? So we are going to be lower
>     in free memory right when it starts up. Right?

GFP_ATOMIC will not be failing at this point (also, kswapd could
probably have reclaimed several hundred or thousand pages in 1ms,
but that's besides the point -- we do have correct buffering here).

The watermarks go roughly like this:

high -- kswapd stops reclaiming
low  -- kswapd is started by any allocation, nothing else happens
min  -- non-GFP_ATOMIC can't go below this point; enter direct reclaim
min/X-- GFP_ATOMIC allocations fail below this point
0    -- PF_MEMALLOC fails.

-- 
SUSE Labs, Novell Inc.
-
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/