Re: [PATCH RFC 3/3] slub: reparent memcg caches' slabs on memcg offline

[Vladimir Davydov]

On Thu, May 15, 2014 at 10:16:39AM -0500, Christoph Lameter wrote:
> On Thu, 15 May 2014, Vladimir Davydov wrote:
> 
> > I admit that's far not perfect, because kfree is really a hot path,
> > where every byte of code matters, but unfortunately I don't see how we
> > can avoid this in case we want slab re-parenting.
> 
> 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").

> > Again, I'd like to hear from you if there is any point in moving in this
> > direction, or I should give up and concentrate on some other approach,
> > because you'll never accept it.
> 
> 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.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/