Re: large page patch (fwd) (fwd)

From: Linus Torvalds (
Date: Sun Aug 04 2002 - 13:38:12 EST

On Sun, 4 Aug 2002, Hubertus Franke wrote:
> As of the page coloring !
> Can we tweak the buddy allocator to give us this additional functionality?

I would really prefer to avoid this, and get "95% coloring" by just doing
read-ahead with higher-order allocations instead of the current "loop
allocation of one block".

I bet that you will get _practically_ perfect coloring with just two small

 - do_anonymous_page() looks to see if the page tables are empty around
   the faulting address (and check vma ranges too, of course), and
   optimistically does a non-blocking order-X allocation.

   If the order-X allocation fails, we're likely low on memory (this is
   _especially_ true since the very fact that we do lots of order-X
   allocations will probably actually help keep fragementation down
   normally), and we just allocate one page (with a regular GFP_USER this

   Map in all pages.

 - do the same for page_cache_readahead() (this, btw, is where radix trees
   will kick some serious ass - we'd have had a hard time doing the "is
   this range of order-X pages populated" efficiently with the old hashes.

I bet just those fairly small changes will give you effective coloring,
_and_ they are also what you want for doing small superpages.

And no, I do not want separate coloring support in the allocator. I think
coloring without superpage support is stupid and worthless (and
complicates the code for no good reason).


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

This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:25 EST