Colin Cross <ccross@xxxxxxxxxxx> writes:
> Userspace processes often have multiple allocators that each do
> anonymous mmaps to get memory. When examining memory usage of
> individual processes or systems as a whole, it is useful to be
> able to break down the various heaps that were allocated by
> each layer and examine their size, RSS, and physical memory
> usage.
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.
Have you done any benchmarks that stress the mm subsystem?
How can adding glittler to /proc/<pid>/maps and /proc/<pid>/smaps
justify putting a hand break on the linux kernel?
Eric
> +/**
> + * vma_name_get
> + *
> + * Increment the refcount of an existing vma_name. No locks are needed because
> + * the caller should already be holding a reference, so refcount >= 1.
> + */
> +void vma_name_get(struct vma_name *vma_name)
> +{
> + if (WARN_ON(!vma_name))
> + return;
> +
> + WARN_ON(!atomic_read(&vma_name->refcount));
> +
> + atomic_inc(&vma_name->refcount);
> +}
> +
> +/**
> + * vma_name_put
> + *
> + * Decrement the refcount of an existing vma_name and free it if necessary.
> + * No locks needed, takes the cache lock if it needs to remove the vma_name from
> + * the cache.
> + */
> +void vma_name_put(struct vma_name *vma_name)
> +{
> + int ret;
> +
> + if (WARN_ON(!vma_name))
> + return;
> +
> + WARN_ON(!atomic_read(&vma_name->refcount));
> +
> + /* fast path: refcount > 1, decrement and return */
> + if (atomic_add_unless(&vma_name->refcount, -1, 1))
> + return;
> +
> + /* slow path: take the lock, decrement, and erase node if count is 0 */
> + write_lock(&vma_name_cache_lock);
> +
> + ret = atomic_dec_return(&vma_name->refcount);
> + if (ret == 0)
> + rb_erase(&vma_name->rb_node, &vma_name_cache);
> +
> + write_unlock(&vma_name_cache_lock);
> +
> + if (ret == 0)
> + kfree(vma_name);
> +}
--
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>