On 07/03, Colin Cross wrote: > > On Wed, Jul 3, 2013 at 9:54 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > Colin Cross <ccross@xxxxxxxxxxx> writes: > > > > What is the advantage of this? It looks like it is going to add cache > > line contention (atomic_inc/atomic_dec) to every vma operation > > especially in the envision use case of heavy vma_name sharing. > > > > I would expect this will result in a bloated vm_area_struct and a slower > > mm subsystem. > > The advantage is better tracking of the impact of various userspace > allocations on the overall system. Userspace could track allocations > on its own, but it cannot track things like physical memory usage or > Kernel SamePage Merging per allocation. What I can't understand completely is why do you need the string to mark the vma's. Just make it "unsigned long vm_id" and avoid all these complications with get/put and "struct vma_name". And afaics you can avoid other complications too, the new argumnent for vma_merge() is not really needed. This patch would be trivial. > I expect "hand break" is overstating the impact. The code complexity (and even size) does matter too ;) It is not clear if this new feature worth the trouble. Oleg. -- 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>