Re: [PATCH v5 4/5] cgroup/cpuset: Documentation update for partition

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

 



On 8/2/23 17:01, Tejun Heo wrote:
Hello, Waiman.

On Thu, Jul 13, 2023 at 01:26:00PM -0400, Waiman Long wrote:
...
+	When a valid partition is created, the value of this file will
+	be automatically set to the largest subset of "cpuset.cpus"
+	that can be granted for exclusive access from its parent if
+	its value isn't explicitly set before.
+
+	Users can also manually set it to a value that is different from
+	"cpuset.cpus".	In this case, its value becomes invariant and
+	may no longer reflect the effective value that is being used
+	to create a valid partition if some dependent cpuset control
+	files are modified.
+
+	There are constraints on what values are acceptable to this
+	control file.  If a null string is provided, it will invalidate a
+	valid partition root and reset its invariant state.  Otherwise,
+	its value must be a subset of the cgroup's "cpuset.cpus" value
+	and the parent cgroup's "cpuset.cpus.exclusive" value.
As I wrote before, the hidden state really bothers me. This is fine when
there is one person configuring the system, but working with automated
management and monitoring tools can be really confusing at scale when there
are hidden states like this as there's no way to determine the current state
by looking at what's visible at the interface level.

Can't we do something like the following?

* cpuset.cpus.exclusive can be set to any possible cpus. While I'm not
   completely against failing certain writes (e.g. siblings having
   overlapping masks is never correct or useful), expanding that to
   hierarchical checking quickly gets into trouble around what happens when
   an ancestor retracts a CPU.

   I don't think it makes sense to reject writes if the applied rules can't
   be invariants for the same reason given for avoiding hidden states - the
   system can be managed by multiple agents at different delegation levels.
   One layer changing resource configuration shouldn't affect the success or
   failure of configuration operations in other layers.

* cpuset.cpus.exclusive.effective shows what's currently available for
   exclusive usage - ie. what'd be used for a partition if the cgroup is to
   become a partition at that point.

   This, I think, gets rid of the need for the hidden states. If .exclusive
   of a child of a partition is empty, its .exclusive.effective can show all
   the CPUs allowed in it. If .exclusive is set then, .exclusive.effective
   shows the available subset.

What do you think?

Sure, I can add cpuset.cpus.exclusive.effective and allow users to set cpuset.cpus.exclusive to whatever they want, just like cpuset.cpus. I will rework the patch series and send out a new version sometimes next week.

With the new cpuset.cpus.exclusive.effective file, cpuset.cpus.exclusive will really be invariant and become whatever the users set. cpuset.cpus.exclusive.effective file will only have value if cpuset.cpus.exclusive set or it becomes a local partition.

Hopefully this will be the final version.

Cheers,
Longman




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux