On Thu, Feb 2, 2017 at 1:52 PM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On Thu, Feb 02, 2017 at 01:32:19PM -0800, Andy Lutomirski wrote: >> > * Thread mode is explicitly enabled on a cgroup by writing "enable" >> > into "cgroup.threads" file. The cgroup shouldn't have any child >> > cgroups or enabled controllers. >> >> Why do you need to manually turn it on? That is, couldn't it be >> automatic based on what controllers are enabled? > > This came up already but it's not like some controllers are inherently > thread-only. Consider CPU, all in-context CPU cycle consumptions are > tied to the thread; however, we also want to be able to account for > CPU cycles consumed for, for example, memory reclaim or encryption > during writeback. > Is this flexible enough for the real-world usecases? For my use case (if I actually ported over to this), it would mean that I'd have to enable thread mode on the root. What about letting a given process (actually mm, perhaps) live in a cgroup but let the threads be in different cgroups without any particular constraints. Then process-wide stuff would be accounted to the cgroup that owns the process. > >> > * Once enabled, arbitrary sub-hierarchy can be created and threads can >> > be put anywhere in the subtree by writing TIDs into "cgroup.threads" >> > file. Process granularity and no-internal-process constraint don't >> > apply in a threaded subtree. >> >> I'm a bit worried that this conflates two different things. There's >> thread support, i.e. allowing individual threads to be placed into >> cgroups. There's also more flexible sub-hierarchy support, i.e. >> relaxing no-internal-process constraints. For the "cpuacct" >> controller, for example, both of these make sense. But what if >> someone writes a controller (directio, for example, just to make >> something up) for which thread granularity makes sense but relaxing >> no-internal-process constraints does not? > > If a controller can't possibly define how internal competition should > be handled, which is unlikely - the problem is being consistent and > sensible, defining something isn't difficult - the controller can > simply error out those cases either on configuration or migration. > Again, I'm very doubtful we'll need that but if we ever need that > denying specific configurations is the best we can do anyway. > I'm not sure I follow. I'm suggesting something quite simple: let controllers that don't need the no-internal-process constraints set a flag so that the constraints don't apply if all enabled controllers have the flag set. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
