Hello, Glauber. On Fri, Jun 07, 2013 at 02:32:34PM +0400, Glauber Costa wrote: > It seems quite valid for me to split priority threads in a process and > give them a 80 % timeslice guarantee, while leaving only 20 % for > low-prio threads (for instance). > > In general, I don't think that it would hurt to allow separation at > thread level *for the leaves*, specifically at the cpu related controllers. But if you look at the larger picture, it actually is deterimental, because allowing different threads of the same process almost implies that the program binary itself would be involved in interacting with - accessing and tuning - cgroups. Back to sysctl analogy, it's one thing to expose them to base system tools which are tightly coupled with the kernel so that they can configure it, but allowing lay programs to embed sysctl tuning inside their binaries is a completely different thing and something which must not happen. While not strictly designated explicitly, things exposed from the kernel have differing levels of exposedness and we do definitely want to avoid exposing too much implementation details for the sake of both the kernel and userland. Such levels are in some cases determined as the use cases develop. If you ask me, cgroup is a good example of things going horribly wrong. So, yeah, while I agree that per-thread usages could make sense for scheduler related controllers, I'd very much like to avoid that if at all possible. It's not a good road to be on. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
