> On Sun, Jul 12, 1998 at 07:10:52PM +0200, Gerard Roudier wrote:
>
> > This has been proven to be broken, at least with the current VM/MM stuff.
> > Trying hard to get 2 contiguous pages leads very often to throw away more
> > that half the available cached objects, regardless the actual memory size
> > being used.
>
> One of the fundamental proporties of the buddy system is that it only
> allocations PAGE_SIZE << order aligned chunks. This is unnecessary for
> most allocations whith order > 0. If __get_free_pages could return
What is necessary is _not_ to use an allocation strategy that increases
the entropy up to complete mess-up.
Buddy is fairly simple, fast and does a _good_ work in this regard.
The problem is the try_to_free stuff and friends that are rather blind.
Anyway, allocation of several contiguous pages cannot be guaranteed
at any time, regardless the cleverness of the allocation algorithm
that is used, and a system that locks because it requires such an
allocation to be always possible is somewhere bogus, IMO.
> unaligned memory as well, the fragmentation issues would be far less
Do you suggest that we should walk all the pages on each allocation
greater that 1 PAGE ?
> problematic. When doing some page colouring hacks for MIPS recently I
> was pretty surprised how many continguous chunks > PAGE_SIZE are still
> available when the fragmentation has already reached the point where
> the machine locks up.
Page colouring fragments, so page colouring may have adverse effects and
you may get opposite effects with all kinds of optimization heuristics,
especially when they are used at the same time.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html