On 11/27/2017 04:04 PM, Tejun Heo wrote: > 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..? Sure. >> + cpuset.effective_mems > Ditto. Sure. >> + 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. That is added because the mem_migrate feature is used in libvirt, I think. I am thinking of add a "[EXPERIMENTAL]" tag to the flags to indicate that it is subject to change. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
