Re: [Workman-devel] cgroup: status-quo and userland efforts
From: Tejun Heo
Date: Mon Apr 08 2013 - 15:20:35 EST
On Mon, Apr 08, 2013 at 03:11:05PM -0400, Vivek Goyal wrote:
> > What if the program crashes?
> I am not sure about this. I guess when applications comes back after crash,
> it can go through all the children cgroups and reclaim empty cgroups.
Fragile, right? What are you arguing here?
> > Wouldn't it make more sense to just have
> > a central arbitrator that everyone talks to?
> May be. Just that in the past folks have not liked the idea of talking
> to central authority to figure out resource group of an object they are
What we've been doing seems tragically broken to me, so I'm not sure
"people didn't use to do it that way" is a good point.
> > What's the benefit of
> > distributing the responsiblities here? It's not like we can put them
> > in different security domains.
> To me it makes sense in a way, as these resources associated with the
> service is just one another property and there does not seem to be
> anything special about this property that it should be managed using
> a single centralized authority.
> For example, one might want to say that maximum IO bandwidth for
> virtual machine virt1 on disk sda should be 10MB/s. Now libvirt
> should be able to save it in virtual machine specific configuration
> easily and whenever virtual machine is started, create a children
> cgroup, set the limits as specified.
Yes, sure, libvirt can *request* whatever it seems appropriate to the
central authority, which will decide whether it'll be able to honor
the request and grant it if possible and allowed by policies in
> That would make sense. systemd had this conflict with cgconfig
> too. Problem is that systemd starts first and sets up everything. Now
> if there is a service which sets up cgroups, after systemd startup,
> it is already late.
Come on, that's not a difficult or fundamental problem. Whatever the
central authority may be, systemd can use it to setup the initial
hierarchy or set up bare-bone hierarchy in compatible manner. This
isn't that different from udev.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/