This is the mail archive of the
mailing list for the glibc project.
Re: FOR REVIEW: New x86-64 vsyscall vgetcpu()
- From: Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>
- To: ak at suse dot de
- Cc: discuss at x86-64 dot org, libc-alpha at sourceware dot org
- Date: 14 Jun 2006 12:46:11 -0000
- Subject: Re: FOR REVIEW: New x86-64 vsyscall vgetcpu()
- References: <email@example.com>
> - 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.
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?
Hmm, in that case: how about a new /dev/nodemem which would behave
like /dev/zero but supply the node and cache information 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.