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.
T.
[1]
$ sudo mount -t cgroup -o cpu,cpuacct cgroups /mnt/cgroups
$ ls /mnt/cgroups/
cgroup.event_control cpuacct.stat cpuacct.usage_percpu
cpu.rt_runtime_us cpu.rt_task_runtime_us notify_on_release tasks
cgroup.procs cpuacct.usage cpu.rt_period_us
cpu.rt_task_period_us cpu.shares release_agent
$ cat /mnt/cgroups/cpu.rt_*
1000000
950000
100000
20000
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso
------------------------------------------------------------------------------
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
