On Wed, Oct 16, 2013 at 1:34 PM, Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > On 10/16/2013 01:00 PM, Colin Cross wrote: >>> > I guess this feature would be used with allocators tightly >>> > so my concern of kernel approach like this that it needs mmap_sem >>> > write-side lock to split/merge vmas which is really thing >>> > allocators(ex, tcmalloc, jemalloc) want to avoid for performance win >>> > that allocators have lots of complicated logic to avoid munmap which >>> > needs mmap_sem write-side lock but this feature would make it invalid. >> My expected use case is that the allocator will mmap a new large chunk >> of anonymous memory, and then immediately name it, resulting in taking >> the mmap_sem twice in a row. > > I guess the prctl (or a new one) _could_ just set a kernel-internal > variable (per-thread?) that says "point any future anonymous areas at > this name". That way, you at least have the _possibility_ of not having > to do it for _every_ mmap(). That won't work for multiple allocators. A thread can easily allocate through Java, then call into native code and allocate through malloc, and those will need different names. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>