Messages in this thread | | | From | Josh Don <> | Date | Thu, 3 Dec 2020 16:51:42 -0800 | Subject | Re: [PATCH -tip 26/32] sched: Add a second-level tag for nested CGroup usecase |
| |
On Wed, Dec 2, 2020 at 12:02 AM Peter Zijlstra <peterz@infradead.org> wrote: > > On Tue, Dec 01, 2020 at 10:18:00PM -0800, Josh Don wrote: > > Hey Peter, > > > > On Wed, Nov 25, 2020 at 5:43 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > > > Why can't the above work by setting 'tag' (that's a terrible name, why > > > does that still live) in CDE? Have the most specific tag live. Same with > > > that thread stuff. > > > > The motivation is to allow an unprivileged user the ability to > > configure the trust hierarchy in a way that otherwise wouldn't be > > possible for a given cgroup hierarchy. For example given a cookie'd > > hierarchy such as: > > > > A > > / | | \ > > B C D E > > > > the user might only want subsets of {B, C, D, E} to share. For > > instance, the user might only want {B,C} and {D, E} to share. One way > > to solve this would be to allow the user to write the group cookie > > directly. However, this interface would need to be restricted to > > privileged users, since otherwise the cookie could be configured to > > share with any arbitrary cgroup. The purpose of the 'color' field is > > to expose a portion of the cookie that can be modified by a > > non-privileged user in order to achieve this sharing goal. > > > > If this doesn't seem like a useful case, I'm happy to drop this patch > > from the series to unblock it. > > Well, the traditional cgroup way of doing that would be to: > > A > / \ > T1 T2 > / \ > B C > > And tag T1 if you want B,C to share. > > So me the color thing reads like an end-run around the cgroup hierarchy.
Restructuring the cgroup resource hierarchy to incorporate the trust domains is not necessarily trivial (as is the case for us). I agree though that that would be the ideal correct solution from the cgroup hierarchy perspective.
| |