lkml.org 
[lkml]   [2005]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Avoiding external fragmentation with a placement policy Version 12
--On Thursday, June 02, 2005 09:09:23 +1000 Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Joel Schopp wrote:
>
>>
>> Other than the very minor whitespace changes above I have nothing bad to
>> say about this patch. I think it is about time to pick in up in -mm for
>> wider testing.
>>
>
> It adds a lot of complexity to the page allocator and while
> it might be very good, the only improvement we've been shown
> yet is allocating lots of MAX_ORDER allocations I think? (ie.
> not very useful)

I agree that MAX_ORDER allocs aren't interesting, but we can hit
frag problems easily at way less than max order. CIFS does it, NFS
does it, jumbo frame gigabit ethernet does it, to name a few. The
most common failure I see is order 3.

Keep a machine up for a while, get it thoroughly fragmented, then
push it reasonably hard constant pressure, and try allocating anything
large.

Seems to me we're basically pointing a blunderbuss at memory, and
blowing away large portions, and *hoping* something falls out the
bottom that's a big enough chunk?

M.

-
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: 2005-06-02 01:41    [from the cache]
©2003-2011 Jasper Spaans