Re: Avoiding external fragmentation with a placement policy Version12

[Nick Piggin]

Martin J. Bligh wrote:
> --On Thursday, June 02, 2005 09:09:23 +1000 Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:

> > 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. 

Still? We had a lot of problems with kswapd not doing its
job properly, and min_free_kbytes reserve was buggy...

But if you still trigger it, I would be interested to see
traces. I don't frequently test things like XFS, or heavy
gige+jumbo loads.

> 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?

Yeah more or less. But with the fragmentation patch, it by
no means becomes an exact science ;) I wouldn't have thought
it would make it hugely easier to free an order 2 or 3 area
memory block on a loaded machine.

It does make MAX_ORDER allocations _possible_ when previously
they wouldn't have been, simply by virtue of trying to put all
memory that it knows is reclaimable in a MAX_ORDER area. When
memory fills up and you need an order 3 allocation, you're
more or less in the same boat AFAIKS.

Why not just have kernel allocations going from the bottom
up, and user allocations going from the top down. That would
get you most of the way there, wouldn't it? (disclaimer: I
could well be talking shit here).

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/