Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp351130ybz; Fri, 24 Apr 2020 17:34:53 -0700 (PDT) X-Google-Smtp-Source: APiQypKt7A2R1q+9ovBfzHc7YGCfGeztiXR5rULtuaNB9IpUSinUK53x4NNZ/t76pFGGZzdh1w1l X-Received: by 2002:aa7:d311:: with SMTP id p17mr10070612edq.73.1587774892927; Fri, 24 Apr 2020 17:34:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587774892; cv=none; d=google.com; s=arc-20160816; b=rMR4B8c0yftkGIBzTbVqgZ8VYtr8hSfpV/NKCt4dVIhKPsdbb2nVFjbe9tmIvb6WMj wi561Pv48qJ4p5xD91/PBGZkbHMpNBOIVZeblwsj6T/uOOu4mfY9rHHcGKg3NwrpJ9Yr bBIOOxGpef0SHyK3C+vnAWHPgYOSTK8LjSaX15cwnAzF5WSqf1A1COsu5p0hRxzUzbyc ZydeEGPw6VPoTN7SCEXnBc/oNEYersZfFWog//Bpo4IxrirUSesOjBXBMbSiwsS5RlxH YueTfr/iVAHV4arS6SmRdNK1Ex3T0tUiNeTSk0pkysuRzAXaJ1vZfuun3c1TvC6WIorJ W4Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=/vs1Hs2P9WS+XpmbV/rX4h9NxAyoSdPPzyICAP3rSWE=; b=xIQz3AAOzLnXwKCVPtkKrPFbn6B+qPExo8sikf3hKMCXbspOhLuxZYAHob8gEr9If7 3byChFq3TIwWBb8+FctTXUf6/gxQYFOjUQjZhozXi48DE7X+MYx3y6ENXm5rfglsF45+ xPbngdmOMgk/94Q5D7x7X3bqHLuSuAxE5kqmmF8tuzJcgjbq+/a6WG4IrctJOqkzOmzu YRfhhbLscCp8aTY7ABiNJJCwfpkKRRn+7gjis7/E1UD4sLAwNow4/zE+VGnY38c0tOxB wS3vj+SCSbim55dHrFiggaqWq7MpJVjXsAgr2osFzfRUG0+Gf8mtJb0yi2vMPeOqYXVY lLpg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t6si3623026edj.527.2020.04.24.17.34.30; Fri, 24 Apr 2020 17:34:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726117AbgDYAc0 (ORCPT + 99 others); Fri, 24 Apr 2020 20:32:26 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:49886 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725874AbgDYAc0 (ORCPT ); Fri, 24 Apr 2020 20:32:26 -0400 Received: from fsav401.sakura.ne.jp (fsav401.sakura.ne.jp [133.242.250.100]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 03P0WAqF060160; Sat, 25 Apr 2020 09:32:10 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav401.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav401.sakura.ne.jp); Sat, 25 Apr 2020 09:32:10 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav401.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 03P0W4sI060047 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Apr 2020 09:32:10 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Subject: Re: [patch] mm, oom: stop reclaiming if GFP_ATOMIC will start failing soon To: David Rientjes , Andrew Morton Cc: Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: From: Tetsuo Handa Message-ID: <6ed3e585-394a-42ff-03c4-a9bb8b5fcbc4@I-love.SAKURA.ne.jp> Date: Sat, 25 Apr 2020 09:32:02 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/04/25 5:48, David Rientjes wrote: > @@ -4372,11 +4372,21 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order, > ac->nodemask) { > unsigned long available; > unsigned long reclaimable; > + unsigned long free; > unsigned long min_wmark = min_wmark_pages(zone); > bool wmark; > > + free = zone_page_state_snapshot(zone, NR_FREE_PAGES); > + /* > + * If this zone is approaching the point where even order-0 > + * GFP_ATOMIC allocations will fail, stop considering reclaim. > + */ > + if (!__zone_watermark_ok(zone, 0, min_wmark, ac_classzone_idx(ac), > + alloc_flags | ALLOC_HIGH, free)) > + continue; This is to trigger the OOM killer more aggressively, isn't it? But where is the guarantee that this is an allocation request which can trigger the OOM killer? If this is an allocation request which cannot trigger the OOM killer, wouldn't this cause premature allocation failures? > + > available = reclaimable = zone_reclaimable_pages(zone); > - available += zone_page_state_snapshot(zone, NR_FREE_PAGES); > + available += free; > > /* > * Would the allocation succeed if we reclaimed all >