On Mon, May 04, 2020 at 06:11:13PM +0200, Michal Hocko wrote: > On Mon 04-05-20 23:24:35, Yafang Shao wrote: > > On Mon, May 4, 2020 at 8:46 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > [...] > > > But the oom situation and the oom report is simply something an admin > > > has to expect especially when the hard limit is set to 0. With kmem > > > accounting there is no guarantee that the target will be met. > > > > I'm always wondering that why not moving the kmem from this memcg to > > the root_mem_cgroup in this situation ? > > Then this memcg can be easily reclaimed. It's not that trivial: there are many objects which are keeping a reference to a memory cgroup. We don't even have a comprehensive list of them. And we should somehow reassign them to a different cgroup without too much overhead. Also it's better to move it to the parent instead of root. > > Roman was playing with kmem charges reparenting. Slabs are already reparenting. Other objects, which are allocated directly by the page allocator (e.g. vmallocs) are not. But it will be relatively easy to cover them after landing my slab controller rework patchset: https://lore.kernel.org/lkml/20200422204708.2176080-1-guro@xxxxxx/ . Basically it provides a framework for charging kernel objects in a way that provides inexpensive reparenting. Thanks!
