[lkml]   [2001]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: page_launder() on 2.4.9/10 issue

--On Thursday, September 06, 2001 12:07 PM -0300 Rik van Riel
<> wrote:

> On many systems, higher-order allocations are a really really
> small fraction of the allocations, so ideally we'd have them
> take the burden of memory fragmentation and won't punish the
> normal allocations.

The only nit being, every instance Stephan's reported so far,
and in most other reports I've seen, the allocation
has been GFP_ATOMIC (i.e. with mask without __GFP_WAIT).
For non-atomic >0 order allocations we already have some
good logic that does (b) via page_launder(), and
where necessary reclaim_page(),__free_page().

So waiting until we are in the high order allocation
allocation is too late, as we don't have room to move.

I think we need to defragment / avoid fragmentation
BEFORE the GFP_ATOMIC high order allocation comes along.
I have some ideas I'd like to test tonight.

Alex Bligh
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:02    [W:0.052 / U:2.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site