Messages in this thread | | | Date | Mon, 27 Nov 2017 13:04:11 -0800 | From | Tejun Heo <> | Subject | Re: [PATCH v3] cpuset: Enable cpuset controller in default hierarchy |
| |
Hello, Waiman.
Sorry about the long delay.
On Fri, Oct 06, 2017 at 05:10:30PM -0400, Waiman Long wrote: > +Cpuset Interface Files > +~~~~~~~~~~~~~~~~~~~~~~ > + > + cpuset.cpus > + A read-write multiple values file which exists on non-root > + cgroups. > + > + It lists the CPUs allowed to be used by tasks within this > + cgroup. The CPU numbers are comma-separated numbers or > + ranges. For example: > + > + # cat cpuset.cpus > + 0-4,6,8-10 > + > + An empty value indicates that the cgroup is using the same > + setting as the nearest cgroup ancestor with a non-empty > + "cpuset.cpus" or all the available CPUs if none is found. > + > + The value of "cpuset.cpus" stays constant until the next update > + and won't be affected by any CPU hotplug events. > + > + cpuset.effective_cpus
Can we do cpuset.ecpus in the fashion of euid, egid..?
> + cpuset.effective_mems
Ditto.
> + cpuset.flags > + A read-write multiple values file which exists on non-root > + cgroups. > + > + It lists the flags that are set (with a '+' prefix) and those > + that are not set (with a '-' prefix). The currently supported > + flag is: > + > + mem_migrate > + When it is not set, an allocated memory page will > + stay in whatever node it was allocated independent > + of changes in "cpuset.mems". > + > + When it is set, tasks with memory pages not in > + "cpuset.mems" will have those pages migrated over to > + memory nodes specified in "cpuset.mems". Any changes > + to "cpuset.mems" will cause pages in nodes that are > + no longer valid to be migrated over to the newly > + valid nodes.
Let's start just with [e]cpus and [e]mems. The flags interface looks fine but the implementations of these features are really bad and cgroup2 doesn't migrate resources for other controllers either anyway.
Thanks.
-- tejun
| |