Re: [patch] mm: Reimplementation of dynamic percpu memory allocator

[Ravikiran G Thirumalai]

On Mon, Jan 17, 2005 at 02:11:17PM -0800, Andrew Morton wrote:
> Ravikiran G Thirumalai <kiran@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/