Hey, Daniel. On Tue, Jun 04, 2013 at 12:15:56PM +0100, Daniel P. Berrange wrote: > With libvirt and KVM we require the ability to put different threads I really don't think cgroup has ever been intended (if there were ever any such overall intending) or is suited for something as fine grained as in-process resource management. There already are existing per-thread interfaces for that. Please use them instead. cgroup simply doesn't fit. > in different cgroups for the "cpu", "cpuset" & "cpuacct" controllers. cpu and cpuacct are in the process of being merged. The scheduler people hate the duplicate accounting the separation causes and cpuacct is generally considered a mistake that we shouldn't repeat. So, umm, you're really depending on a lot of things which are considered big mistakes in cgroup. > This is to allow us to control schedular tunables / placement for > QEMU vCPU threads, independantly of limits for QEMU I/O threads. So > requiring all threads of a process to be in the same cgroup isn't > sufficiently flexible for our needs. It was never suited to that level of flexibility and it will never be and things like that will be clearly forbidden rather than being left in the current "not fully supported but kinda works" state. The existing stuff won't break but new things won't keep the support. If you're fine with staying with the old interface, which will be around for the foreseeable future, that's fine too, but if you intend to move onto the new interface when it finally becomes ready, whenever that is, please move on. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
