Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp2966258rwb; Mon, 5 Sep 2022 04:33:32 -0700 (PDT) X-Google-Smtp-Source: AA6agR6IMcaQ97lyc9AVZMZ/E03E1mgpCFcQj1DyoPAfQlSY9hrOxjGuWtx0DkeY/i02HoHfwMiK X-Received: by 2002:a17:902:f693:b0:174:46d7:fb91 with SMTP id l19-20020a170902f69300b0017446d7fb91mr45553214plg.6.1662377611980; Mon, 05 Sep 2022 04:33:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662377611; cv=none; d=google.com; s=arc-20160816; b=xk1JI+0DffdVlPGPhcqdltRWFiCBKOffnTkq6NKAUl8quCnIIQpaeB0xmkMUmhJmtl yOpDSO9cqN/fXVAog0FIEuyMeNXra0DkCNjG3/6a7FX3FeOUNSbug39ECxUBdA81LNW6 uKG4+jmFVvCs9ZLOeiW9FtLzDRthKlvvASvWmBYLmCC7kZPIqlCQptzZo2Cbauo2Phsi hn1Jx7pGfOo1wwH3hCVxpwe8fumYJU4fGZu+t3ovjwlyLA6tYOvOtTeEFPUWSv/P3hSc QbuSfvBMKn8+1DI3GZl9oksyAc+nvWdBcx8QiEfwWy67YX1CLCDWUYHCS6xNaFnkddiV gloQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=jLtoVNiBT2iSspfGxmncgOVgViwjY/ew1M2VzEnJohU=; b=b0+N5N68UEovpkttNVwUDbfgE/K1ZhI405S0h5rWNJ2GGSjo70tyPU4PAxD7iRR1yw pOEX8zwUFy2wGVgQoDm+kX63TyNfoymb9oQ2t1MWbY4iQU3fjM/7sfdQ/tSh185wg6MA H/MyPd4AgFeTfFzUmYISr7hFRjuDmbEaH8QdUNUAtPuYX/99Q6jetMB6l8vEpoZA569H l2toKA09EiXSQcztkxiQpYfXb97K5VeE+YZ7yUJgCGE4Sc+f2cHTtRrXrM9Xj0p/IY3j z01BYnVn+Qw9YHtZQM8pYM6/5oyLpkF6yVhaY4e5+O6PvDfkC4NkjvPpQ3b6QVycZNVn eiZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=tuZx0thW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u4-20020a17090341c400b0016f1c879eacsi4033494ple.109.2022.09.05.04.33.20; Mon, 05 Sep 2022 04:33:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=tuZx0thW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237600AbiIEKvA (ORCPT + 99 others); Mon, 5 Sep 2022 06:51:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236686AbiIEKu5 (ORCPT ); Mon, 5 Sep 2022 06:50:57 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E9C94E631; Mon, 5 Sep 2022 03:50:56 -0700 (PDT) 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 1563338825; Mon, 5 Sep 2022 10:50:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1662375055; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jLtoVNiBT2iSspfGxmncgOVgViwjY/ew1M2VzEnJohU=; b=tuZx0thWhdDNLQb2iOtjt5nsAi8tSL9CQTYd6aMVNNn7Jqg9oia58Jq/f1/Sms2d4R34gW QbXNq3fv1IdAre7JAEgFELRSnd5gXYW7luDDTsw/ZANRbuHIjBY0zx6/uqDFGbNI7gKJ+O /yk03N/hMavkJrXpvO5kxs2pZgVdcUQ= 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 EB231139C7; Mon, 5 Sep 2022 10:50:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id A2UwN47UFWOIUQAAMHmgww (envelope-from ); Mon, 05 Sep 2022 10:50:54 +0000 Date: Mon, 5 Sep 2022 12:50:54 +0200 From: Michal Hocko To: Zhongkun He Cc: hannes@cmpxchg.org, roman.gushchin@linux.dev, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, lizefan.x@bytedance.com, wuyun.abel@bytedance.com Subject: Re: [External] Re: [PATCH] cgroup/cpuset: Add a new isolated mems.policy type. Message-ID: References: <20220904040241.1708-1-hezhongkun.hzk@bytedance.com> <0e5f380b-9201-0f56-9144-ce8449491fc8@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e5f380b-9201-0f56-9144-ce8449491fc8@bytedance.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 05-09-22 18:30:55, Zhongkun He wrote: > Hi Michal, thanks for your reply. > > The current 'mempolicy' is hierarchically independent. The default value of > the child is to inherit from the parent. The modification of the child > policy will not be restricted by the parent. This breaks cgroup fundamental property of hierarchical enforcement of each property. And as such it is a no go. > Of course, there are other options, such as the child's policy mode must be > the same as the parent's. node can be the subset of parent's, but the > interleave type will be complicated, that's why hierarchy independence is > used. It would be better if you have other suggestions? Honestly, I am not really sure cgroup cpusets is a great fit for this usecase. It would be probably better to elaborate some more what are the existing shortcomings and what you would like to achieve. Just stating the syscall is a hard to use interface is not quite clear on its own. Btw. have you noticed this question? > > What is the hierarchical behavior of the policy? Say parent has a > > stronger requirement (say bind) than a child (prefer)? > > > How to use the mempolicy interface: > > > echo prefer:2 > /sys/fs/cgroup/zz/cpuset.mems.policy > > > echo bind:1-3 > /sys/fs/cgroup/zz/cpuset.mems.policy > > > echo interleave:0,1,2,3 >/sys/fs/cgroup/zz/cpuset.mems.policy > > > > Am I just confused or did you really mean to combine all these > > together? -- Michal Hocko SUSE Labs