Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory

[Yang Shi]

On 10/9/17 11:53 AM, Yang Shi wrote:
> On 10/8/17 11:36 PM, Michal Hocko wrote:
> > On Mon 09-10-17 08:33:16, Michal Hocko wrote:
> > > On Sat 07-10-17 00:37:55, Yang Shi wrote:
> > > > On 10/6/17 2:37 AM, Michal Hocko wrote:
> > > > > On Thu 05-10-17 05:29:10, Yang Shi wrote:
> > > [...]
> > > > > > +    list_for_each_entry_safe(s, s2, &slab_caches, list) {
> > > > > > +        if (!is_root_cache(s) || (s->flags & SLAB_RECLAIM_ACCOUNT))
> > > > > > +            continue;
> > > > > > +
> > > > > > +        memset(&sinfo, 0, sizeof(sinfo));
> > > > >
> > > > > why do you zero out the structure. All the fields you are printing are
> > > > > filled out in get_slabinfo.
> > > >
> > > > No special reason, just wipe out the potential stale data on the stack.
> > >
> > > Do not add code that has no meaning. The OOM killer is a slow path but
> > > that doesn't mean we should throw spare cycles out of the window.
> >
> > With this fixed and the compile fix [1] folded, feel free to add my
> > Acked-by: Michal Hocko <mhocko@xxxxxxxx>
> >
> > [1] 
> > http://lkml.kernel.org/r/1507492085-42264-1-git-send-email-yang.s@xxxxxxxxxxxxxxx 
>
> Did some more thorough test and took the code a little deeper, it sounds 
> !CONFIG_SLOB is not enough. Some data structure and functions depends on 
> CONFIG_SLUB_DEBUG, i.e. kmem_cache_node->total_objects and 
> node_nr_objs(), which are essential of get_slabinfo().
>
> So, I'm supposed it makes more sense to protect the related slab stats 
> code and the unreclaimable slabinfo dump with CONFIG_SLAB || 
> CONFIG_SLUB_DEBUG.

This is needed to solve compile error when CONFIG_SLUB && !CONFIG_SLUB_DEBUG

Yang

> Thanks,
> Yang
>
> >