From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34228C83003 for ; Wed, 29 Apr 2020 10:45:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F1D7F2072A for ; Wed, 29 Apr 2020 10:45:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1D7F2072A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=i-love.sakura.ne.jp Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 720F58E0005; Wed, 29 Apr 2020 06:45:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6AA928E0001; Wed, 29 Apr 2020 06:45:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5722A8E0005; Wed, 29 Apr 2020 06:45:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id 3BF818E0001 for ; Wed, 29 Apr 2020 06:45:27 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DAED4181AEF07 for ; Wed, 29 Apr 2020 10:45:26 +0000 (UTC) X-FDA: 76760561052.08.note39_125858e677404 X-HE-Tag: note39_125858e677404 X-Filterd-Recvd-Size: 2970 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Wed, 29 Apr 2020 10:45:25 +0000 (UTC) Received: from fsav404.sakura.ne.jp (fsav404.sakura.ne.jp [133.242.250.103]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 03TAjHEc016517; Wed, 29 Apr 2020 19:45:17 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav404.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav404.sakura.ne.jp); Wed, 29 Apr 2020 19:45:17 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav404.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 03TAjAE5016499 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2020 19:45:16 +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: Michal Hocko Cc: Vlastimil Babka , David Rientjes , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman References: <20200425172706.26b5011293e8dc77b1dccaf3@linux-foundation.org> <20200427133051.b71f961c1bc53a8e72c4f003@linux-foundation.org> <28e35a8b-400e-9320-5a97-accfccf4b9a8@suse.cz> <31f1f84d-c5fe-824b-3c28-1a9ad69fcae5@suse.cz> <20200429090437.GX28637@dhcp22.suse.cz> From: Tetsuo Handa Message-ID: Date: Wed, 29 Apr 2020 19:45:07 +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: <20200429090437.GX28637@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2020/04/29 18:04, Michal Hocko wrote: > Completely agreed! The in kernel OOM killer is to deal with situations > when memory is desperately depleted without any sign of a forward > progress. If there is a reclaimable memory then we are not there yet. > If a workload can benefit from early oom killing based on response time > then we have facilities to achieve that (e.g. PSI). Can PSI work even if userspace process cannot avoid reclaimable memory allocations (e.g. page fault, file read) is already stalling? I'm not sure whether PSI allows responding quickly enough to "keep reclaimable memory allocations not to reclaim" despite there is still reclaimable memory...