On 05/31/2018 11:58 AM, Tejun Heo wrote: > Hello, > > On Thu, May 31, 2018 at 09:22:23AM -0400, Waiman Long wrote: >>>>>>> As the intersection of g11's cpus and that of g1 is empty, the effective >>>>>>> cpus of g11 is just that of g1. The check in update_cpumask() is now >>>>>>> corrected to make sure that cpus in a child cpus must be a subset of >>>>>>> its parent's cpus. The error "write error: Invalid argument" will now >>>>>>> be reported in the above case. >>>>>>> >>>>>> We made the distinction between user-configured CPUs and effective CPUs >>>>>> in commit 7e88291beefbb758, so actually it's not a bug. >>>>>> >>>>> I remember the original reason is to support restoration of the original >>>>> cpu after cpu offline->online. We use user-configured CPUs to remember >>>>> if the cpu should be restored in the cpuset after it's onlined. >>>> AFAICT you can do that and still have the child a subset of the parent, >>>> no? >>>> . >>> Sure. IIRC this was suggested by Tejun as he had done something similar to devcgroup. >>> >> OK, let wait until Tejun has time to chime in. For me, it just look >> weird to be able to do that. >> >> Another corner case that is not handled is when cpus_allowed is empty. >> In this case, it falls back to the parent's effective cpus. On the other >> hand, it can also be argued that an empty cpus_allowed is a transient >> state and a cpuset shouldn't have cpus undefined while creating children. > Tying together what's configured and what's applied may feel > attractive on the surface but it's a long term headache. > > * It's inconsistent with what other controllers are doing. All the > limit resource configs declare the upper bound the specific cgroup > can consume regardless of what's actually available to it. They > limit but don't guarantee access. > > * Which decouples a given cgroup's configurations from its ancestors', > which allows an ancestor to take away resources that it granted > before and then also giving it back later. No matter what you do, > if you couple configs of cgroup hierarchy, you end up restricting > what an ancestor can do to its sub-hierarchy, which can quickly > become a difficult operational headache. > > So, let's please stay away from it even if that means a bit of > overhead in terms of interface. > > Thanks. > I am fine with that argument. I will update the patch documentation to include this information as I think it is important for the users to be aware of that. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
