From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753577AbdJaQsQ (ORCPT ); Tue, 31 Oct 2017 12:48:16 -0400 Received: from out0-224.mail.aliyun.com ([140.205.0.224]:33043 "EHLO out0-224.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752335AbdJaQsP (ORCPT ); Tue, 31 Oct 2017 12:48:15 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R161e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03275;MF=yang.s@alibaba-inc.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---.9HovZJL_1509468481; Subject: Re: [PATCH 2/2] mm: oom: dump single excessive slab cache when oom 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: <1508971740-118317-1-git-send-email-yang.s@alibaba-inc.com> <1508971740-118317-3-git-send-email-yang.s@alibaba-inc.com> <20171026145312.6svuzriij33vzgw7@dhcp22.suse.cz> <44577b73-2e2d-5571-4c8b-3233e3776a52@alibaba-inc.com> <20171026162701.re4lclnqkngczpcl@dhcp22.suse.cz> <20171026171414.mwetwu43hnxavwfn@dhcp22.suse.cz> From: "Yang Shi" Message-ID: <43776378-91f8-45f3-c5af-b1db00d0c6ce@alibaba-inc.com> Date: Wed, 01 Nov 2017 00:47:56 +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: <20171026171414.mwetwu43hnxavwfn@dhcp22.suse.cz> 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/26/17 10:14 AM, Michal Hocko wrote: > On Thu 26-10-17 18:27:01, Michal Hocko wrote: >> On Fri 27-10-17 00:15:17, Yang Shi wrote: >>> >>> >>> On 10/26/17 7:53 AM, Michal Hocko wrote: >>>> On Thu 26-10-17 06:49:00, Yang Shi wrote: >>>>> Per the discussion with David [1], it looks more reasonable to just dump >>>> >>>> Please try to avoid external references in the changelog as much as >>>> possible. >>> >>> OK. >>> >>>> >>>>> the single excessive slab cache instead of dumping all slab caches when >>>>> oom. >>>> >>>> You meant to say >>>> "to just dump all slab caches which excess 10% of the total memory." >>>> >>>> While we are at it. Abusing calc_mem_size seems to be rather clumsy and >>>> tt is not nodemask aware so you the whole thing is dubious for NUMA >>>> constrained OOMs. >>> >>> Since we just need the total memory size of the node for NUMA constrained >>> OOM, we should be able to use show_mem_node_skip() to bring in nodemask. >> >> yes > > to be more specific. This would work for the total number of pages > calculation. This is still not enough, though. You would also have to > filter slabs per numa node and this is getting more and more complicated > for a marginal improvement. Yes, it sounds so. Basically, I agree with you to wait for a while to see how the current implementation is doing. Thanks, Yang >