On Wed, Feb 29, 2012 at 8:47 AM, Glauber Costa [off-list ref] wrote:

On 02/28/2012 07:47 PM, Suleiman Souhlal wrote:

quoted

I hadn't considered the fact that two cgroups could have the same base
name.
I think having a name makes it a lot easier for a human to understand
which cgroup is using slab, so what about having both the base name of
the cgroup AND its css id, so that the caches are named like
"dentry(5:foo)"?

That would be better, so if you really want to keep names, I'd advise you to
go this route.

However, what does "5" really means to whoever is reading that? css ids are
not visible to the user, so there isn't really too much information you can
extract for that. So why not only dentry-5 ?

dentry-5 gives even less information.. :-)

quoted

This should let us use the name of the cgroup while still being able
to distiguish cgroups that have the same base name.

I am fine with name+css_id if you really want names on it.

quoted

quoted

I was thinking: How about we don't bother to show them at all, and
instead,
show a proc-like file inside the cgroup with information about that
cgroup?

One of the patches in the series adds a per-memcg memory.kmem.slabinfo.

I know. What I was wondering was if we wanted to show only the non-cgroup
slabs in /proc/slabinfo, and then show the per-cgroup slabs in the cgroup
only.

I think /proc/slabinfo should show all the slabs in the system, to
avoid confusion.

Thanks for your comments so far.
I will try to get a v2 out soon that addresses them.

-- Suleiman

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>