On Fri, 16 May 2014, Vladimir Davydov wrote:
> > Do we even know that all objects in that slab belong to a certain cgroup?
> > AFAICT the fastpath currently do not allow to make that distinction.
>
> All allocations from a memcg's cache are accounted to the owner memcg,
> so that all objects on the same slab belong to the same memcg, a pointer
> to which can be obtained from the page->slab_cache->memcg_params. At
> least, this is true since commit faebbfe10ec1 ("sl[au]b: charge slabs to
> kmemcg explicitly").
I doubt that. The accounting occurs when a new cpu slab page is allocated.
But the individual allocations in the fastpath are not accounted to a
specific group. Thus allocation in a slab page can belong to various
cgroups.
> > I wish you would find some other way to do this.
>
> The only practical alternative to re-parenting I see right now is
> periodic reaping, but Johannes isn't very fond of it, and his opinion is
> quite justified, because having caches that will never be allocated from
> hanging around indefinitely, only because they have a couple of active
> objects to be freed, doesn't look very good.
If all objects in the cache are in use then the slab page needs to hang
around since the objects presence is required. You may not know exactly
which cgroups these object belong to. The only thing that you may now (if
you keep a list of full slabs) is which cgroup was in use then the
slab page was initially allocated.
Isnt it sufficient to add a counter of full slabs to a cgroup? When you
allocate a new slab page add to the counter. When an object in a slab page
is freed and the slab page goes on a partial list decrement the counter.
That way you can avoid tracking full slabs.
--
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>