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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55CDDC433F5 for ; Sat, 23 Oct 2021 15:01:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8B29C60FDA for ; Sat, 23 Oct 2021 15:01:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8B29C60FDA 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=kvack.org Received: by kanga.kvack.org (Postfix) id C289080007; Sat, 23 Oct 2021 11:01:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BE61E940007; Sat, 23 Oct 2021 11:01:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A50ED80007; Sat, 23 Oct 2021 11:01:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0230.hostedemail.com [216.40.44.230]) by kanga.kvack.org (Postfix) with ESMTP id 8FEF4940007 for ; Sat, 23 Oct 2021 11:01:30 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 33BD2181FE074 for ; Sat, 23 Oct 2021 15:01:30 +0000 (UTC) X-FDA: 78728015940.18.DD328F9 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf26.hostedemail.com (Postfix) with ESMTP id 0E62320019EC for ; Sat, 23 Oct 2021 15:01:29 +0000 (UTC) Received: from fsav113.sakura.ne.jp (fsav113.sakura.ne.jp [27.133.134.240]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 19NF18CF008358; Sun, 24 Oct 2021 00:01:08 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav113.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav113.sakura.ne.jp); Sun, 24 Oct 2021 00:01:08 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav113.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 19NF17p2008355 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 Oct 2021 00:01:07 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH memcg v3 2/3] mm, oom: do not trigger out_of_memory from the #PF To: Vasily Averin , Michal Hocko Cc: Roman Gushchin , Uladzislau Rezki , Vlastimil Babka , Shakeel Butt , Mel Gorman , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@openvz.org, Johannes Weiner , Vladimir Davydov , Andrew Morton References: From: Tetsuo Handa Message-ID: Date: Sun, 24 Oct 2021 00:01:07 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0E62320019EC X-Stat-Signature: 1oox9jffs8jh1hu7rpbuii7cjo8shz3f Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=none; spf=none (imf26.hostedemail.com: domain of penguin-kernel@i-love.sakura.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@i-love.sakura.ne.jp X-HE-Tag: 1635001289-426031 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 2021/10/23 22:20, Vasily Averin wrote: > /* > - * The pagefault handler calls here because it is out of memory, so kill a > - * memory-hogging task. If oom_lock is held by somebody else, a parallel oom > - * killing is already in progress so do nothing. > + * The pagefault handler calls here because some allocation has failed. We have > + * to take care of the memcg OOM here because this is the only safe context without > + * any locks held but let the oom killer triggered from the allocation context care > + * about the global OOM. > */ Excuse me for a stupid question. I consider if (!mutex_trylock(&oom_lock)) return; out_of_memory(&oc); mutex_unlock(&oom_lock); here as the last resort (safeguard) when neither __alloc_pages_may_oom() nor mem_cgroup_out_of_memory() can make progress. This patch says let the oom killer triggered from the allocation context care about the global OOM. but what if the OOM killer cannot be invoked from the allocation context? Is there a guarantee that all memory allocations which might result in VM_FAULT_OOM can invoke the OOM killer?