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 A182AC433F5 for ; Thu, 21 Oct 2021 08:04:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1A67E611CC for ; Thu, 21 Oct 2021 08:04:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1A67E611CC Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=virtuozzo.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B383E6B0071; Thu, 21 Oct 2021 04:04:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE800940008; Thu, 21 Oct 2021 04:04:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D725940007; Thu, 21 Oct 2021 04:04:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id 9141D6B0071 for ; Thu, 21 Oct 2021 04:04:12 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 431601801D53C for ; Thu, 21 Oct 2021 08:04:12 +0000 (UTC) X-FDA: 78719706744.05.9D18FB6 Received: from relay.sw.ru (relay.sw.ru [185.231.240.75]) by imf25.hostedemail.com (Postfix) with ESMTP id 5F3E6B00008E for ; Thu, 21 Oct 2021 08:04:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Content-Type:MIME-Version:Date:Message-ID:From: Subject; bh=nC/QVr0jtd67Au3q+jnUAluZhpYLLVaIrvqIUdLTEDo=; b=Wtw08hMyX+W4NLre+ n9xyyyWTQ+7yVckdtj4NgGGt3H07Uadf+aq/kXQ0s9YmKasnSl8h0WaWckzAzJbaxdJDikq3o2EtK PjakBSQeCbhcuQsyynQ5dQ/mJmVCGoPXQEHuzCe+/lntmiujD0qXlJrOGynXblB6Roux8XZG5w2DY =; Received: from [172.29.1.17] by relay.sw.ru with esmtp (Exim 4.94.2) (envelope-from ) id 1mdT3V-006gm0-IB; Thu, 21 Oct 2021 11:04:05 +0300 Subject: Re: [PATCH memcg 0/1] false global OOM triggered by memcg-limited task To: Michal Hocko Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , 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 References: <9d10df01-0127-fb40-81c3-cc53c9733c3e@virtuozzo.com> From: Vasily Averin Message-ID: <496ed57e-61c6-023a-05fd-4ef21b0294cf@virtuozzo.com> Date: Thu, 21 Oct 2021 11:03:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.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-Queue-Id: 5F3E6B00008E Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=virtuozzo.com header.s=relay header.b=Wtw08hMy; spf=pass (imf25.hostedemail.com: domain of vvs@virtuozzo.com designates 185.231.240.75 as permitted sender) smtp.mailfrom=vvs@virtuozzo.com; dmarc=pass (policy=quarantine) header.from=virtuozzo.com X-Stat-Signature: ncdb99hquzmy4grc98efmpt1jb818hig X-Rspamd-Server: rspam06 X-HE-Tag: 1634803447-576699 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 18.10.2021 12:04, Michal Hocko wrote: > On Mon 18-10-21 11:13:52, Vasily Averin wrote: > [...] >> How could this happen? >> >> User-space task inside the memcg-limited container generated a page fault, >> its handler do_user_addr_fault() called handle_mm_fault which could not >> allocate the page due to exceeding the memcg limit and returned VM_FAULT_OOM. >> Then do_user_addr_fault() called pagefault_out_of_memory() which executed >> out_of_memory() without set of memcg. > I will be honest that I am not really happy about pagefault_out_of_memory. > I have tried to remove it in the past. Without much success back then, > unfortunately[1]. > > [1] I do not have msg-id so I cannot provide a lore link but google > pointed me to https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1400402.html I re-read this discussion and in general I support your position. As far as I understand your opponents cannot explain why "random kill" is mandatory here, they are just afraid that it might be useful here and do not want to remove it completely. Ok, let's allow him to do it. Moreover I'm ready to keep it as default behavior. However I would like to have some choice in this point. In general we can: - continue to use "random kill" and rely on the wisdom of the ancestors. - do nothing, repeat #PF and rely on fate: "nothing bad will happen if we do it again". - add some (progressive) killable delay, rely on good will of (unkillable) neighbors and wait for them to release required memory. - mark the current task as cycled in #PF and somehow use this mark in allocator - make sure that the current task is really cycled, have no progress, send him fatal signal to kill it and break the cycle. - implement any better ideas, - use any combination of previous points We can select required strategy for example via sysctl. For me "random kill" is worst choice, Why can't we just kill the looped process instead? It can be marked as oom-unkillable, so OOM-killer was unable to select it. However I doubt it means "never kill it", for me it is something like "last possible victim" priority. Thank you, Vasily Averin