[PATCH cgroup/for-3.11 1/3] cgroup: mark "tasks" cgroup file as insane

[Li Zefan]

On 2013/6/5 4:19, Tejun Heo wrote:
> 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, 

I don't think this can be an option for libvirt. When some other user
applications (systemd for example) use the new unified hierarchy interface,
then the old interface is no longer available for libvirt.

> but if you intend to move
> onto the new interface when it finally becomes ready, whenever that
> is, please move on.
> 
> Thanks.
>