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

[Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>]

Hi,

> I really don't see the benefit here. malloc already gets pages handed
> down from the kernel which are node local due to them being assigned at
> a first touch basis.

That's only true for the very first allocation!  malloc is all about
"recycling" memory from freed previous allocations.

> I am not sure about glibc's malloc internals, but
> rather rely on a vgetcpu() call, all it really needs to do is to keep
> a thread local pool which will automatically get it's thing locally
> through first touch usage.

When a malloc() call is serviced, there are often several
possibilities from where to fulfill the request.
ptmalloc (current in glibc) has several pools (arenas)
but currently can not discern them in any way except that
of course it prefers the last used one.

> I don't see how a new syscall is going to provide anything to malloc
> that it doesn't already have. What am I missing?
 
With vgetcpu() one could easily record the node that allocated the
arena _and_ use that for later malloc() calls in case there is freed
memory available within an arena.

Regards,
Wolfram.