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. Balbir ------------------------------------------------------------------------------ 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
