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 CA1E9C43217 for ; Thu, 1 Dec 2022 12:45:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DAA456B0072; Thu, 1 Dec 2022 07:45:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D5A136B0073; Thu, 1 Dec 2022 07:45:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFBD66B0074; Thu, 1 Dec 2022 07:45:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B048D6B0072 for ; Thu, 1 Dec 2022 07:45:00 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 74054401EA for ; Thu, 1 Dec 2022 12:45:00 +0000 (UTC) X-FDA: 80193707160.16.E22C4B9 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf12.hostedemail.com (Postfix) with ESMTP id CDEBB40014 for ; Thu, 1 Dec 2022 12:44:59 +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-out1.suse.de (Postfix) with ESMTPS id 1E60621AC2; Thu, 1 Dec 2022 12:44:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1669898698; 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=2usVyVHvq6UpCYGTeYatlo+CIODmj9sJULa7nXifL7I=; b=hVlPQZhQULbKSaUOF1Ptr93R7UHM2CFgYMqevAQOi+JuvHhxUFBIvxcFSM2Vh7Djf7zhEL dlFAaCNFppiO/tq30A6MzlbBRIYJXya8GMZ+SOvkebJl/TRVMO1i2Tyy8KA1wVap+1o63F rrwgJlk321vFBTdqNpCzEqeY/yXhzEU= 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 EB1CB13503; Thu, 1 Dec 2022 12:44:57 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id mpA4OcmhiGM3eAAAGKfGzw (envelope-from ); Thu, 01 Dec 2022 12:44:57 +0000 Date: Thu, 1 Dec 2022 13:44:57 +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=1669898700; 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=2usVyVHvq6UpCYGTeYatlo+CIODmj9sJULa7nXifL7I=; b=6XF7L57QMQCtcq976kPPxX6w1xx70VIo+T8RJ/2n9ONPis4Qx4XoH84d21ohGCAONvAZa3 3hSy7x/FnqAzjFcHmI2xgdBtuYMEizTRXubq66M5i9hFg/19QJHiKvM53pcWRFW4nvrB28 +SF3SJgUDi23gdX4d9Z5srC7t+J1FgY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=hVlPQZhQ; spf=pass (imf12.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=1669898700; a=rsa-sha256; cv=none; b=lf0cQKez9saXI91Hy6ZOihoDprL0cWmsz10Q68udJPQDDT2KWAfFb24D9oba6OlKpxFLhp XUqL9BML8MBMmWLLBs5nmGfM06elvFfhYbnAacl1DWF76FnGmmY6VXQ4b+tQ4x2FcaiSWz yXWSViAJzUSINXJoGQ97SH+xA7iPS2s= X-Stat-Signature: i9ce4fop7fbju8856ynm4rxees4s1koy X-Rspam-User: X-Rspamd-Queue-Id: CDEBB40014 X-Rspamd-Server: rspam11 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=hVlPQZhQ; spf=pass (imf12.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-HE-Tag: 1669898699-566290 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 10:52:35, 程垲涛 Chengkaitao Cheng wrote: > At 2022-12-01 16:49:27, "Michal Hocko" wrote: > >On Thu 01-12-22 04:52:27, 程垲涛 Chengkaitao Cheng wrote: > >> At 2022-12-01 00:27:54, "Michal Hocko" wrote: > >> >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. > >> > >> usecases 1: users say that they want to protect an important process > >> with high memory consumption from being killed by the oom in case > >> of docker container failure, so as to retain more critical on-site > >> information or a self recovery mechanism. At this time, they suggest > >> setting the score_adj of this process to -1000, but I don't agree with > >> it, because the docker container is not important to other docker > >> containers of the same physical machine. If score_adj of the process > >> is set to -1000, the probability of oom in other container processes will > >> increase. > >> > >> usecases 2: There are many business processes and agent processes > >> mixed together on a physical machine, and they need to be classified > >> and protected. However, some agents are the parents of business > >> processes, and some business processes are the parents of agent > >> processes, It will be troublesome to set different score_adj for them. > >> Business processes and agents cannot determine which level their > >> score_adj should be at, If we create another agent to set all processes's > >> score_adj, we have to cycle through all the processes on the physical > >> machine regularly, which looks stupid. > > > >I do agree that oom_score_adj is far from ideal tool for these usecases. > >But I also agree with Roman that these could be addressed by an oom > >killer implementation in the userspace which can have much better > >tailored policies. OOM protection limits would require tuning and also > >regular revisions (e.g. memory consumption by any workload might change > >with different kernel versions) to provide what you are looking for. > > There is a misunderstanding, oom.protect does not replace the user's > tailed policies, Its purpose is to make it easier and more efficient for > users to customize policies, or try to avoid users completely abandoning > the oom score to formulate new policies. Then you should focus on explaining on how this makes those policies and easier and moe efficient. I do not see it. [...] > >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. -- Michal Hocko SUSE Labs