lkml.org 
[lkml]   [2007]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-08-29 02:17    [W:0.043 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site