Messages in this thread |  | | Date | Mon, 12 Nov 2001 13:19:42 -0500 | From | Jeff Garzik <> | Subject | Re: [patch] arbitrary size memory allocator, memarea-2.4.15-D6 |
| |
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
- 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/
|  |