On Fri, Apr 22, 2022 at 08:46:07PM -0400, Kent Overstreet wrote: > On Fri, Apr 22, 2022 at 05:27:41PM -0700, Roman Gushchin wrote: > > You're scanning over a small portion of all shrinker lists (on a machine with > > cgroups), so the top-10 list has little value. > > Global ->count_objects() return the number of objects on the system/root_mem_cgroup > > level, not the shrinker's total. > > Not quite following what you're saying here...? > > If you're complaining that my current top-10-shrinker report isn't memcg aware, > that's valid - I can fix that. For memcg-aware shrinkers each memcg has it's own LRU (per node). If you want to print top-10 system-wide lists you need to call ->count_objects() for each shrinker for each memcg for each node. It's quite a lot of work for an oom context. > > > > In my experience, it's rare to be _so_ out of memory that small kmalloc > > > allocations are failing - we'll be triggering the show_mem() report before that > > > happens. > > > > I agree. However the OOM killer _has_ to make the progress even in such rare > > circumstances. > > Oh, and the concern is allocator recursion? Yeah, that's a good point. Yes, but not the only problem. > > Do you know if using memalloc_noreclaim_(save|restore) is sufficient for that, > or do we want GFP_ATOMIC? I'm already using GFP_ATOMIC for allocations when we > generate the report on slabs, since we're taking the slab mutex there. And this is another problem: grabbing _any_ locks from the oom context is asking for trouble: you can potentially enter the oom path doing any allocation, so now you have to check that no allocations are ever made holding this lock. And I'm not aware of any reasonable way to test it, so most likely it ends up introducing some very subtle bags, which will be triggered once a year. Thanks!
