[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-mm
Subject:    Re: [RFC][PATCH] __alloc_pages_limit & order > 0
From:       Rik van Riel <riel () conectiva ! com ! br>
Date:       2001-08-25 3:20:59
[Download RAW message or body]

On Sat, 25 Aug 2001, Roger Larsson wrote:

> To begin with if order > 0 then direct_reclaim will be false even if
> it is allowed to wait...

That's because direct_reclaim can only reclaim 1 page from
the page cache at the same time, while a higher-order alloc
needs _multiple_ pages.

Thus, by definition, a direct-reclaim won't satisfy a higher
order allocation.

> This version allows direct_reclaim with order > 0 !

The old code already did this, albeit in a very ugly way.

I'd like to see the old code cleaned up, but I'm not too happy
about the main loop being complicated because of these (very rare)
higher-order allocations.

IIRC somebody measured his system one day and 99.5% of the allocs
were 0-order GFP_USER or GFP_KERNEL, so I guess we really want to
keep the multi-order allocs from messing with the main allocation
loop.

Then again, please do clean up the multi-order allocation page
cleaning loop, the way I coded it originally is just plain ugly ;)

regards,

Rik -- after a few drinks, so apply a grain of salt ;)
-- 
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

[prev in list] [next in list] [prev in thread] [next in thread]