Re: [RFC PATCH 0/5] cgroup/cpuset: A new "isolcpus" paritition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello.

The previous thread arrived incomplete to me, so I respond to the last
message only. Point me to a message URL if it was covered.

On Fri, Apr 14, 2023 at 03:06:27PM -0400, Waiman Long <longman@xxxxxxxxxx> wrote:
> Below is a draft of the new cpuset.cpus.reserve cgroupfs file:
> 
>   cpuset.cpus.reserve
>         A read-write multiple values file which exists on all
>         cpuset-enabled cgroups.
> 
>         It lists the reserved CPUs to be used for the creation of
>         child partitions.  See the section on "cpuset.cpus.partition"
>         below for more information on cpuset partition.  These reserved
>         CPUs should be a subset of "cpuset.cpus" and will be mutually
>         exclusive of "cpuset.cpus.effective" when used since these
>         reserved CPUs cannot be used by tasks in the current cgroup.
> 
>         There are two modes for partition CPUs reservation -
>         auto or manual.  The system starts up in auto mode where
>         "cpuset.cpus.reserve" will be set automatically when valid
>         child partitions are created and users don't need to touch the
>         file at all.  This mode has the limitation that the parent of a
>         partition must be a partition root itself.  So child partition
>         has to be created one-by-one from the cgroup root down.
> 
>         To enable the creation of a partition down in the hierarchy
>         without the intermediate cgroups to be partition roots,

Why would be this needed? Owning a CPU (a resource) must logically be
passed all the way from root to the target cgroup, i.e. this is
expressed by valid partitioning down to given level.

>         one
>         has to turn on the manual reservation mode by writing directly
>         to "cpuset.cpus.reserve" with a value different from its
>         current value.  By distributing the reserve CPUs down the cgroup
>         hierarchy to the parent of the target cgroup, this target cgroup
>         can be switched to become a partition root if its "cpuset.cpus"
>         is a subset of the set of valid reserve CPUs in its parent.

level n
`- level n+1
   cpuset.cpus	// these are actually configured by "owner" of level n
   cpuset.cpus.partition // similrly here, level n decides if child is a partition

I.e. what would be level n/cpuset.cpus.reserve good for when it can
directly control level n+1/cpuset.cpus?

Thanks,
Michal

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux