Re: [patch] arbitrary size memory allocator, memarea-2.4.15-D6

[Jeff Garzik <jgarzik@mandrakesoft.com>]

Ingo Molnar wrote:
> the attached memarea-2.4.15-D6 patch does just this: it implements a new
> 'memarea' allocator which uses the buddy allocator data structures without
> impacting buddy allocator performance. It has two main entry points:
> 
>         struct page * alloc_memarea(unsigned int gfp_mask, unsigned int pages);
>         void free_memarea(struct page *area, unsigned int pages);
> 
> the main properties of the memarea allocator are:
> 
>  - to be an 'unlimited size' allocator: it will find and allocate 100 GB
>    of physically continuous memory if that much RAM is available.
[...]
> Obviously, alloc_memarea() can be pretty slow if RAM is getting full, nor
> does it guarantee allocation, so for non-boot allocations other backup
> mechanizms have to be used, such as vmalloc(). It is not a replacement for
> the buddy allocator - it's not intended for frequent use.

What's wrong with bigphysarea patch or bootmem?  In the realm of frame
grabbers this is a known and solved problem...

With bootmem you know that (for example) 100GB of physically contiguous
memory is likely to be available; and after boot, memory get fragmented
and the likelihood of alloc_memarea success decreases drastically...
just like bootmem.

Back when I was working on the Matrox Meteor II driver, which requires
as large of a contiguous RAM area as you can give it, bootmem was
suggested as the solution.

IMHO your patch is not needed.  If someone needs a -huge- slab of
memory, then they should allocate it at boot time when they are sure
they will get it.  Otherwise it's an exercise in futility, because they
will be forced to use a fallback method like vmalloc anyway.

	Jeff



-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno