Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751825AbdISXDc (ORCPT ); Tue, 19 Sep 2017 19:03:32 -0400 Received: from out0-236.mail.aliyun.com ([140.205.0.236]:50213 "EHLO out0-236.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751619AbdISXDb (ORCPT ); Tue, 19 Sep 2017 19:03:31 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R141e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03307;MF=yang.s@alibaba-inc.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---.8wfo9Af_1505862195; Subject: Re: [PATCH 2/2] mm: oom: show unreclaimable slab info when kernel panic To: David Rientjes Cc: cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, mhocko@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <1505759209-102539-1-git-send-email-yang.s@alibaba-inc.com> <1505759209-102539-3-git-send-email-yang.s@alibaba-inc.com> <01f4cce4-d7a3-2fcb-06e0-382eff8e83e5@alibaba-inc.com> From: "Yang Shi" Message-ID: <11acb4bd-a1bf-cc32-a124-d98bf746f201@alibaba-inc.com> Date: Wed, 20 Sep 2017 07:03:14 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2503 Lines: 80 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. >