On Mon, Jan 17, 2005 at 02:11:17PM -0800, Andrew Morton wrote: > Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote: > > > > > So... is it not possible to enhance vmalloc() for node-awareness, then > > > just use it? > > > > > > > Memory for block management (free lists, bufctl lists) is also resident > > in one block. A typical block in this allocator looks like this: > > > > I still don't get it. It is possible to calculate the total size of the > block beforehand, yes? So why not simply vmalloc_numa() a block of that > size then populate it?
I should be excited to add a new api ;), but, then we would have something like: void *vmalloc_numa(unsigned long size, unsigned long extra) which would 1. Allocate (size * NR_CPUS + extra) worth of va space (vm_struct) 2. Allocate node local pages amounting to 'size' for each possible cpu 3. Allocate pages for 'extra' 4. Mapping 'size' amount of pages allocated for cpus to corresponding va space beginning from vm_struct.addr to (vm_struct.addr + NR_CPUS * size - 1) 5. Map vm_struct.addr + NR_CPUS * size to pages allocated for extra in (3). It is the need for this 'extra' -- the block management memory, which made me think against a common api outside the allocator. If you feel vmalloc_numa is the right approach, I will make a patch to put it in vmalloc.c in the next iteration. Thanks, Kiran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
