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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
