* Dhaval Giani <[email protected]> [2010-06-30 21:14:26]:
> 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 saw that part, from the kernel design perspective root should 100%
of the resources, so to be honest root levels should not matter.
Having said that I don't know what the rt controller does. So for
memory at-least root levels don't matter.
> 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.
>
--
Three Cheers,
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
