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 4F530C433FE for ; Wed, 30 Nov 2022 16:28:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D99776B0074; Wed, 30 Nov 2022 11:28:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D23CC6B0075; Wed, 30 Nov 2022 11:28:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B9CFB6B0078; Wed, 30 Nov 2022 11:28:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A89A46B0074 for ; Wed, 30 Nov 2022 11:28:00 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 808C840AD6 for ; Wed, 30 Nov 2022 16:28:00 +0000 (UTC) X-FDA: 80190640320.29.4FF420F Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf01.hostedemail.com (Postfix) with ESMTP id BEC1040019 for ; Wed, 30 Nov 2022 16:27:56 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (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-out1.suse.de (Postfix) with ESMTPS id 014482129A; Wed, 30 Nov 2022 16:27:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1669825675; 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=nXfNG6Sww8fGURySTb8eVABizwa45hjeSXnodgsxL7A=; b=K5AhfMD1mmeSLfJHmy5N+Z9Fp6PpPk7Tg6j3Gg7JBI1HUIpk9Q1kujuQk6AXGNNyV145KQ d9PwmobJ2stCSZPjUM0avskb5R4vue2G5ijhEc6FYiczmjflCS0mD9rGkb6uCxCJrsuy3j g3oV+3D2ydZVm0DCiTt0qtKaJSdI6oU= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (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 imap2.suse-dmz.suse.de (Postfix) with ESMTPS id D03D313A70; Wed, 30 Nov 2022 16:27:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id pufuMYqEh2NEPgAAMHmgww (envelope-from ); Wed, 30 Nov 2022 16:27:54 +0000 Date: Wed, 30 Nov 2022 17:27:54 +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: <7EF16CB9-C34A-410B-BEBE-0303C1BB7BA0@didiglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7EF16CB9-C34A-410B-BEBE-0303C1BB7BA0@didiglobal.com> ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=K5AhfMD1; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 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=1669825677; a=rsa-sha256; cv=none; b=UvTBUJAQ0rxLTxLYQ3/Xf/z8EITPVWEBBp2c+IqyVQ2L8o1qqpJKLwYMb5j8+yj4gN/9VR EkG4yiFK3gY9Txg6CKGSFAWCfu4cLwLVBEVgzy9U52pkJ8AhMc+kxLo2xZRK9DA4J3qKXN cqPRlmFGmmTYqLB4riIVOVY1pMIzCWE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669825677; 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=nXfNG6Sww8fGURySTb8eVABizwa45hjeSXnodgsxL7A=; b=uNLEuBwcdYEHD3U53vg1MFv0ewFxPPSUvipKf47NPzQm6bEmJp2cx85vIHU92sf6z6YPee 4Rm/Y/NjkpvT1i8kpEsk/vW/hI21uJgprl4gtc8IOC/ZQvudQDFpU5E/bJdIrNNP5LO1gx wxXW5bbfpY7uNs8Qz479sCf45m3UVdQ= Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=K5AhfMD1; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam01 X-Stat-Signature: zs6yz9ucgndojzr3hsft8r9px6ocibk4 X-Rspamd-Queue-Id: BEC1040019 X-Rspam-User: X-HE-Tag: 1669825676-44067 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 Wed 30-11-22 15:46:19, 程垲涛 Chengkaitao Cheng wrote: > On 2022-11-30 21:15:06, "Michal Hocko" wrote: > > On Wed 30-11-22 15:01:58, chengkaitao wrote: > > > From: chengkaitao > > > > > > We created a new interface for memory, If there is > > > the OOM killer under parent memory cgroup, and the memory usage of a > > > child cgroup is within its effective oom.protect boundary, the cgroup's > > > tasks won't be OOM killed unless there is no unprotected tasks in other > > > children cgroups. It draws on the logic of in the > > > inheritance relationship. > > > > Could you be more specific about usecases? This is a very important question to answer. > > How do you tune oom.protect > > wrt to other tunables? How does this interact with the oom_score_adj > > tunining (e.g. a first hand oom victim with the score_adj 1000 sitting > > in a oom protected memcg)? > > We prefer users to use score_adj and oom.protect independently. Score_adj is > a parameter applicable to host, and oom.protect is a parameter applicable to cgroup. > When the physical machine's memory size is particularly large, the score_adj > granularity is also very large. However, oom.protect can achieve more fine-grained > adjustment. Let me clarify a bit. I am not trying to defend oom_score_adj. It has it's well known limitations and it is is essentially unusable for many situations other than - hide or auto-select potential oom victim. > When the score_adj of the processes are the same, I list the following cases > for explanation, > > root > | > cgroup A > / \ > cgroup B cgroup C > (task m,n) (task x,y) > > score_adj(all task) = 0; > oom.protect(cgroup A) = 0; > oom.protect(cgroup B) = 0; > oom.protect(cgroup C) = 3G; How can you enforce protection at C level without any protection at A level? This would easily allow arbitrary cgroup to hide from the oom killer and spill over to other cgroups. > usage(task m) = 1G > usage(task n) = 2G > usage(task x) = 1G > usage(task y) = 2G > > oom killer order of cgroup A: n > m > y > x > oom killer order of host: y = n > x = m > > If cgroup A is a directory maintained by users, users can use oom.protect > to protect relatively important tasks x and y. > > However, when score_adj and oom.protect are used at the same time, we > will also consider the impact of both, as expressed in the following formula. > but I have to admit that it is an unstable result. > score = task_usage + score_adj * totalpage - eoom.protect * task_usage / local_memcg_usage I hope I am not misreading but this has some rather unexpected properties. First off, bigger memory consumers in a protected memcg are protected more. Also I would expect the protection discount would be capped by the actual usage otherwise excessive protection configuration could skew the results considerably. > > I haven't really read through the whole patch but this struck me odd. > > > > @@ -552,8 +552,19 @@ static int proc_oom_score(struct seq_file *m, struct pid_namespace *ns, > > > unsigned long totalpages = totalram_pages() + total_swap_pages; > > > unsigned long points = 0; > > > long badness; > > > +#ifdef CONFIG_MEMCG > > > + struct mem_cgroup *memcg; > > > > > > - badness = oom_badness(task, totalpages); > > > + rcu_read_lock(); > > > + memcg = mem_cgroup_from_task(task); > > > + if (memcg && !css_tryget(&memcg->css)) > > > + memcg = NULL; > > > + rcu_read_unlock(); > > > + > > > + update_parent_oom_protection(root_mem_cgroup, memcg); > > > + css_put(&memcg->css); > > > +#endif > > > + badness = oom_badness(task, totalpages, MEMCG_OOM_PROTECT); > > > > the badness means different thing depending on which memcg hierarchy > > subtree you look at. Scaling based on the global oom could get really > > misleading. > > I also took it into consideration. I planned to change "/proc/pid/oom_score" > to a writable node. When writing to different cgroup paths, different values > will be output. The default output is root cgroup. Do you think this idea is > feasible? I do not follow. Care to elaborate? -- Michal Hocko SUSE Labs