Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Zefan Li <lizefan.x@bytedance.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
	Juri Lelli <juri.lelli@redhat.com>,
	Valentin Schneider <vschneid@redhat.com>,
	Frederic Weisbecker <frederic@kernel.org>
Subject: Re: [RFC PATCH 0/5] cgroup/cpuset: A new "isolcpus" paritition
Date: Fri, 14 Apr 2023 13:29:25 -0400	[thread overview]
Message-ID: <c61ca9d0-c514-fb07-c2f2-3629e8898984@redhat.com> (raw)
In-Reply-To: <ZDmFLfII8EUX_ocY@slm.duckdns.org>


On 4/14/23 12:54, Tejun Heo wrote:
> On Thu, Apr 13, 2023 at 09:22:19PM -0400, Waiman Long wrote:
>> I now have a slightly different idea of how to do that. We already have an
>> internal cpumask for partitioning - subparts_cpus. I am thinking about
>> exposing it as cpuset.cpus.reserve. The current way of creating
>> subpartitions will be called automatic reservation and require a direct
>> parent/child partition relationship. But as soon as a user write anything to
>> it, it will break automatic reservation and require manual reservation going
>> forward.
>>
>> In that way, we can keep the old behavior, but also support new use cases. I
>> am going to work on that.
> I'm not sure I fully understand the proposed behavior but it does sound more
> quirky.

The idea is to use the existing subparts_cpus for cpu reservation 
instead of adding a new cpumask for that purpose. The current way of 
partition creation does cpus reservation (setting subparts_cpus) 
automatically with the constraint that the parent of a partition must be 
a partition root itself. One way to relax this constraint is to allow a 
new manual reservation mode where users can set reserve cpus manually 
and distribute them down the hierarchy before activating a partition to 
use those cpus.

Now the question is how to enable this new manual reservation mode. One 
way to do it is to enable it whenever the new cpuset.cpus.reserve file 
is modified. Alternatively, we may enable it by a cgroupfs mount option 
or a boot command line option.

Hope this can clarify your confusion.

Cheers,
Longman


  reply	other threads:[~2023-04-14 17:30 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-12 15:37 [RFC PATCH 0/5] cgroup/cpuset: A new "isolcpus" paritition Waiman Long
2023-04-12 19:28 ` Tejun Heo
     [not found]   ` <1ce6a073-e573-0c32-c3d8-f67f3d389a28@redhat.com>
2023-04-12 20:22     ` Tejun Heo
2023-04-12 20:33       ` Waiman Long
2023-04-13  0:03         ` Tejun Heo
2023-04-13  0:26           ` Waiman Long
2023-04-13  0:33             ` Tejun Heo
2023-04-13  0:55               ` Waiman Long
2023-04-13  1:17                 ` Tejun Heo
2023-04-13  1:55                   ` Waiman Long
2023-04-14  1:22                     ` Waiman Long
2023-04-14 16:54                       ` Tejun Heo
2023-04-14 17:29                         ` Waiman Long [this message]
2023-04-14 17:34                           ` Tejun Heo
2023-04-14 17:38                             ` Waiman Long
2023-04-14 19:06                               ` Waiman Long
2023-05-02 18:01                                 ` Michal Koutný
2023-05-02 21:26                                   ` Waiman Long
2023-05-02 22:27                                     ` Michal Koutný
2023-05-04  3:01                                       ` Waiman Long
2023-05-05 16:03                                         ` Tejun Heo
2023-05-05 16:25                                           ` Waiman Long
2023-05-08  1:03                                             ` Waiman Long
2023-05-22 19:49                                               ` Tejun Heo
2023-05-28 21:18                                                 ` Waiman Long
2023-06-05 18:03                                                   ` Tejun Heo
2023-06-05 20:00                                                     ` Waiman Long
2023-06-05 20:27                                                       ` Tejun Heo
2023-06-06  2:47                                                         ` Waiman Long
2023-06-06 19:58                                                           ` Tejun Heo
2023-06-06 20:11                                                             ` Waiman Long
2023-06-06 20:13                                                               ` Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c61ca9d0-c514-fb07-c2f2-3629e8898984@redhat.com \
    --to=longman@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=frederic@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=shuah@kernel.org \
    --cc=tj@kernel.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox