Hi, On Thu, Mar 21, 2024 at 09:41:43PM -0400, Waiman Long wrote: > On 3/21/24 17:33, Petr Malat wrote: > > Hi! > > I have tried to use the new remote cgroup feature and I find the > > interface unfriendly - requiring cpuset.cpus.exclusive to be a subset > > of cpuset.cpus requires the program, which wants to isolate a CPU for > > some RT activity, to know what CPUs all ancestor cgroups want to use. > > > > For example consider cgroup hierarchy c1/c2/c3 where my program is > > running and wants to isolate CPU N, so > > - It creates new c1/c2/c3/rt cgroup > > - It adds N to cpuset.cpus.exclusive of rt, c3 and c2 cgroup > > (cpuset.cpus.exclusive |= N) > > - Now it should do the same with cpuset.cpus, but that's not possible > > if ancestors cpuset.cpus is empty, which is common configuration and > > there is no good way how to set it in that case. > > > > My proposal is to > > - Not require cpuset.cpus.exclusive to be a subset of cpuset.cpus > > - Create remote cgroup if cpuset.cpus is empty and local cgroup if it's > > set, to give the user explicit control on what cgroup is created. > > I think we can make cpuset.cpus.exclusive independent of cpuset.cpus as a > separate hierarchy to make creation of remote partitions easier. I need some > more time to think through it. I don't think your test patch is enough for > making this change. BTW, you confuse cpuset.cpus.exclusive with > cpuset.cpus.effective which are two completely different things. The exclusive/effective confusion is a copy and paste mistake in the description, the code should make cpuset.cpus.exclusive independent on cpuset.cpus, how is described in the initial mail. I have pasted it from my clipboard history and apparently haven't read the whole string. P.
