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(). -- 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>