Hello, Waiman. On Sun, Jun 24, 2018 at 03:30:38PM +0800, Waiman Long wrote: > Because of the fact that setting the "cpuset.sched.partition" in > a direct child of root can remove CPUs from the root's effective CPU > list, it makes sense to know what CPUs are left in the root cgroup for > scheduling purpose. So the "cpuset.cpus.effective" control file is now > exposed in the v2 cgroup root. So, effective changing when enabling partition on a child feels wrong to me. It's supposed to contain what's actually allowed to the cgroup from its parent and that shouldn't change regardless of how those resources are used. It's still given to the cgroup from its parent. It's a bit different because the way partition behaves is different from other resource konbs in that it locks away those cpus so that they can't be taken back. What do people think about restricting partition to the first level children for now at least? That way we aren't locked into the special semantics and we can figure out how to this down the hierarchy later. Given that we ignore the regular cpuset settings when the set goes empty (which also is a special condition which only exists for cpuset) and inherits the parent's, I think the consistent thing to do is doing the same for partition - if it can't be satisfied, ignore it, but maybe there is a better way. Thanks. -- tejun -- 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
