This is the mail archive of the 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: FOR REVIEW: New x86-64 vsyscall vgetcpu()


> - 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 ( has made
such an optimization only slightly more difficult, AFAICS.


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