lkml.org 
[lkml]   [2005]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] mm: Reimplementation of dynamic percpu memory allocator
On Mon, Jan 17, 2005 at 02:11:17PM -0800, Andrew Morton wrote:
> Ravikiran G Thirumalai <kiran@in.ibm.com> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.043 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site