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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 554CBC43217 for ; Thu, 1 Dec 2022 13:08:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A64126B0072; Thu, 1 Dec 2022 08:08:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EDE96B0073; Thu, 1 Dec 2022 08:08:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 865E56B0074; Thu, 1 Dec 2022 08:08:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 713606B0072 for ; Thu, 1 Dec 2022 08:08:29 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 48C8C1C6151 for ; Thu, 1 Dec 2022 13:08:29 +0000 (UTC) X-FDA: 80193766338.16.84C4FB6 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf22.hostedemail.com (Postfix) with ESMTP id 6525AC001C for ; Thu, 1 Dec 2022 13:08:28 +0000 (UTC) Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id C27961FD81; Thu, 1 Dec 2022 13:08:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1669900106; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=K/3E4rKV56hZO1ZYVzKhSOwwyXDyBi7M71us9jjagdo=; b=ZC25gQgYpHLJv3sUQUpw833y1NbAm84Kj96hRcqLaxWPqonFdDKoAEQwY8o+h5Urr4f/94 sYhbrouqe8Sz2mT73RyW2KuWQ0ZQZVfQyN3N+lHgNLROGt3f2Q2frfuTwFrG8knt0CulCG XireW5USxtH4hjxIvL59nH4fLlaqq3M= Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id A9BA313503; Thu, 1 Dec 2022 13:08:26 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id uwI1KUqniGPoBQAAGKfGzw (envelope-from ); Thu, 01 Dec 2022 13:08:26 +0000 Date: Thu, 1 Dec 2022 14:08:26 +0100 From: Michal Hocko To: =?utf-8?B?56iL5Z6y5rab?= Chengkaitao Cheng Cc: Tao pilgrim , "tj@kernel.org" , "lizefan.x@bytedance.com" , "hannes@cmpxchg.org" , "corbet@lwn.net" , "roman.gushchin@linux.dev" , "shakeelb@google.com" , "akpm@linux-foundation.org" , "songmuchun@bytedance.com" , "cgel.zte@gmail.com" , "ran.xiaokai@zte.com.cn" , "viro@zeniv.linux.org.uk" , "zhengqi.arch@bytedance.com" , "ebiederm@xmission.com" , "Liam.Howlett@oracle.com" , "chengzhihao1@huawei.com" , "haolee.swjtu@gmail.com" , "yuzhao@google.com" , "willy@infradead.org" , "vasily.averin@linux.dev" , "vbabka@suse.cz" , "surenb@google.com" , "sfr@canb.auug.org.au" , "mcgrof@kernel.org" , "sujiaxun@uniontech.com" , "feng.tang@intel.com" , "cgroups@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , Bagas Sanjaya , "linux-mm@kvack.org" , Greg Kroah-Hartman Subject: Re: [PATCH] mm: memcontrol: protect the memory in cgroup from being oom killed Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669900108; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=K/3E4rKV56hZO1ZYVzKhSOwwyXDyBi7M71us9jjagdo=; b=ZFduK2AYVNNF2GaSAcQsAeWo0lGpLqiNRKAcTOjAbi2cnSRWL2HRjy4iHs3jJge1/U+m4T OLcy+MX4C14Gjl9beYzfz8qQyiiWiXE36l0/tIV/h6Sh4ZPYn+6EZ2LYrtDOR3J7txNUpH uuS5w8XYH2gvVTdB92M8ADC+6JsIy14= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ZC25gQgY; spf=pass (imf22.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669900108; a=rsa-sha256; cv=none; b=HvOVMboc73c1xoGfZqijhUUuHdx3JHb/yOjZ8w+2VFBjwguCG9kSQhUPoN/sWF5/75ZIa1 w45nKgyQGBbekDsbUhi5AtlFasYTcHFamuAaHwuf/yAktsDRj9rKpeEbzSMxuTiI0RByj9 cpJbYkycSN0OXkROz8cbrbvas41795E= X-Stat-Signature: gnerjb5ezubyzatf3nadnj7hnokd9my7 X-Rspamd-Queue-Id: 6525AC001C Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ZC25gQgY; spf=pass (imf22.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1669900108-365141 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 Thu 01-12-22 13:44:58, Michal Hocko wrote: > On Thu 01-12-22 10:52:35, 程垲涛 Chengkaitao Cheng wrote: > > At 2022-12-01 16:49:27, "Michal Hocko" wrote: [...] > > >Why cannot you simply discount the protection from all processes > > >equally? I do not follow why the task_usage has to play any role in > > >that. > > > > If all processes are protected equally, the oom protection of cgroup is > > meaningless. For example, if there are more processes in the cgroup, > > the cgroup can protect more mems, it is unfair to cgroups with fewer > > processes. So we need to keep the total amount of memory that all > > processes in the cgroup need to protect consistent with the value of > > eoom.protect. > > You are mixing two different concepts together I am afraid. The per > memcg protection should protect the cgroup (i.e. all processes in that > cgroup) while you want it to be also process aware. This results in a > very unclear runtime behavior when a process from a more protected memcg > is selected based on its individual memory usage. Let me be more specific here. Although it is primarily processes which are the primary source of memcg charges the memory accounted for the oom badness purposes is not really comparable to the overal memcg charged memory. Kernel memory, non-mapped memory all that can generate rather interesting cornercases. -- Michal Hocko SUSE Labs