On Wed, Jun 30, 2010 at 6:40 PM, Balbir Singh <[email protected]> wrote: > > On Wed, Jun 30, 2010 at 1:46 PM, Tommaso Cucinotta > <[email protected]> wrote: >> >> Il 29/06/2010 19:51, Dhaval Giani ha scritto: >> > We are going to need some sort of dependency constraints. We already >> > have that issue with current rt-cgroups, because, say for example you >> > wish to reduce the period for the root cgroup, you will first need to >> > reduce the runtime, and then the period. So, yes, we do need some sort >> > of dependency ordering. >> > >> I'm not sure such dependencies would suffice. An issue I noticed is >> that, when you unmount the cgroup and mount it again later, the previous >> root-level figures are kept by the kernel [1]. Therefore, assuming a >> sysadmin is playing with rt throttling settings, he/she will have to >> make multiple tries changing the /etc/cgconfig file then restarting the >> cgroup service. However, the exact order in which new settings can be >> safely applied might depend on the previously configured settings (which >> might also remain in a partially inconsistent state, in case there was >> an error in the previous cgconfigparser run). So, the correct order in >> this case would become highly dynamic. Probably this is not to be >> considered as an issue for the libcgroup itself, but rather an issue for >> the cgroupfs, in which this very particular subsystem (rt throttling >> configuration) currently maps in a very bad and quite unusable way. > > libcgroup assumes that all configuration changes are done through it. If a > cgroup mount point is unmounted without freeing groups, libcgroup will have > a challenge. The expectation is that we start from clean slate. Is there a > reason to unmount, mount it back and then reuse cgconfig.conf to recreate > those groups? cgroup service on termination cleans up the filesystem and > deletes all created directories. >
Well, that is not the issue that he talks about. The issue is that the root cgroup retains the values set across different mounts, even when all associated subgroups have been destroyed. I can see only one way out of this then. Layer 2. I will repost those patches sometime soon, it will need to be updated quite a bit. I will post the locking changse in a day or two, and then we can look at those. Thanks, Dhaval ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Libcg-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
