From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755310AbdJIVBF (ORCPT ); Mon, 9 Oct 2017 17:01:05 -0400 Received: from out0-243.mail.aliyun.com ([140.205.0.243]:51982 "EHLO out0-243.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751337AbdJIVBE (ORCPT ); Mon, 9 Oct 2017 17:01:04 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R431e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03289;MF=yang.s@alibaba-inc.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---.95ABxmN_1507582851; Subject: Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory From: "Yang Shi" To: Michal Hocko Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <1507152550-46205-1-git-send-email-yang.s@alibaba-inc.com> <1507152550-46205-4-git-send-email-yang.s@alibaba-inc.com> <20171006093702.3ca2p6ymyycwfgbk@dhcp22.suse.cz> <20171009063316.qjmunbabyr2nzh52@dhcp22.suse.cz> <20171009063642.nykrjazifntrj5zz@dhcp22.suse.cz> <2a24ae2a-e2f3-52b2-0763-2ce31ba18965@alibaba-inc.com> Message-ID: Date: Tue, 10 Oct 2017 05:00:50 +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: <2a24ae2a-e2f3-52b2-0763-2ce31ba18965@alibaba-inc.com> 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 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 >> >> [1] >> http://lkml.kernel.org/r/1507492085-42264-1-git-send-email-yang.s@alibaba-inc.com >> > > 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 > >>