lkml.org 
[lkml]   [2017]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/2] mm: oom: show unreclaimable slab info when kernel panic
From
Date


On 9/19/17 3:41 PM, David Rientjes wrote:
> On Wed, 20 Sep 2017, Yang Shi wrote:
>
>>>> --- a/mm/slab_common.c
>>>> +++ b/mm/slab_common.c
>>>> @@ -35,6 +35,8 @@
>>>> static DECLARE_WORK(slab_caches_to_rcu_destroy_work,
>>>> slab_caches_to_rcu_destroy_workfn);
>>>> +#define K(x) ((x)/1024)
>>>> +
>>>> /*
>>>> * Set of flags that will prevent slab merging
>>>> */
>>>> @@ -1272,6 +1274,34 @@ static int slab_show(struct seq_file *m, void *p)
>>>> return 0;
>>>> }
>>>> +void show_unreclaimable_slab()
>>>> +{
>>>> + struct kmem_cache *s = NULL;
>>>> + struct slabinfo sinfo;
>>>> +
>>>> + memset(&sinfo, 0, sizeof(sinfo));
>>>> +
>>>> + printk("Unreclaimable slabs:\n");
>>>> +
>>>> + /*
>>>> + * Here acquiring slab_mutex is unnecessary since we don't prefer to
>>>> + * get sleep in oom path right before kernel panic, and avoid race
>>>> condition.
>>>> + * Since it is already oom, so there should be not any big allocation
>>>> + * which could change the statistics significantly.
>>>> + */
>>>> + list_for_each_entry(s, &slab_caches, list) {
>>>> + if (!is_root_cache(s))
>>>> + continue;
>>>> +
>>>> + get_slabinfo(s, &sinfo);
>>>> +
>>>> + if (!is_reclaimable(s) && sinfo.num_objs > 0)
>>>> + printk("%-17s %luKB\n", cache_name(s),
>>>> K(sinfo.num_objs * s->size));
>>>> + }
>>>
>>> I like this, but could we be even more helpful by giving the user more
>>> information from sinfo beyond just the total size of objects allocated?
>>
>> Sure, we definitely can. But, the question is what info is helpful to users to
>> diagnose oom other than the size.
>>
>> I think of the below:
>> - the number of active objs, the number of total objs, the percentage
>> of active objs per cache
>> - the number of active slabs, the number of total slabs, the
>> percentage of active slabs per cache
>>
>> Anything else?
>>
>
> Right now it's a useful tool to find out what unreclaimable slab is
> sitting around that is causing the system to run out of memory. If we
> knew how much of this slab is actually in use vs free, it can determine if
> its stranding or if there's a bug in the slab allocator itself.

I see. You prefer to have a report which looks like:

Cache Used size Free size
mm_struct 100K 50K

Or show the total size (used + free) instead of free size. And, may plus
the number of objs and the number of total objs.

Thanks,
Yang

>
> We wouldn't need percentages, we can calculate that directly from the
> data if necessary.
>

\
 
 \ /
  Last update: 2017-09-20 01:04    [W:0.067 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site