This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [discuss] Re: FOR REVIEW: New x86-64 vsyscall vgetcpu()


On Wednesday 14 June 2006 14:46, Wolfram Gloger wrote:
> Hi,
> 
> > - For NUMA optimization in user space you really need to know the current
> > node to find out where to allocate memory from.
> ...
> > My eventual hope is that glibc will be start using this to implement a NUMA aware
> > malloc() in user space that tries to allocate local memory preferably.
> 
> I'm interested in working on this once the syscall(s) are in place.

Great.

I'll let you know when it is in.

> 
> Would one need to record the node where an mmap() was performed, and
> then use that as a hint when several alternative areas are available
> to fulfill a malloc() request?

Yep.

I would just note on which CPU you ran when you did mmap - the kernel
will usually give you "local" memory and that should be good enough.

You will have to save that information somewhere so that you can
return it to the right pool on free (it can be gotten from the kernel,
but it will be probably too slow).

Or the information can be stored indirectly by looking up to which
pool the address belongs.


> Hmm, in that case: how about a new /dev/nodemem which would behave
> like /dev/zero but supply the node 

That can be already gotten from get_mempolicy(). But I wouldn't recommend
to use it. Or at least not in the fast path - it's useful for debugging.

> and cache information 

cache only depends on which CPU used it last.

> for the VMA  
> in a short block at the start of the mapped region (this would be
> guranteed to be correct as opposed to what a vgetcpu() would have
> given before or after the mmap())?
> 
> For ptmalloc2 (current in glibc) such a NUMA optimization should be
> rather straightforward, and current ptmalloc3 (www.malloc.de) has made
> such an optimization only slightly more difficult, AFAICS.

Nice. I'm sure if you could come up with a prototype it would be 
possible to help you benchmark/tune it.

Thanks,

-Andi
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]