lkml.org 
[lkml]   [2023]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC PATCH 0/5] cgroup/cpuset: A new "isolcpus" paritition
From

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

\
 
 \ /
  Last update: 2023-04-14 19:33    [W:0.091 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site