23 Jun
2009
23 Jun
'09
5:27 p.m.
On Tue, Jun 23, 2009 at 2:50 PM, Fernando
Lopez-Lezcano<nando(a)ccrma.stanford.edu> wrote:
This is what Lennart wrote in his original announcement:
> Why not use cgroups for this? Because it's simply a horrible API, and
> using this for media applications has non-obvious consequences on
> using cgroups for their originally intended purpose -- which are
> containers.
The problem with this is that the mechanism described there is
actually not dependent on the use of cgroups at all. It will limit all
!SCHED_OTHER threads whether they are in a cgroup or not. Moreover,
its not clear to me how we should take Lennart's assessment "its
simply a horrible API" when its already been merged into (at least)
the Fedora kernel and perhaps the mainline one (I have not checked).
Its already wierd enough to have RLIMIT_RTPRIO and RTKit both capable
of providing access to !SCHED_OTHER, but when RTKit seems to aiming at
another target already covered by a small part of the already merged
cgroup stuff, it gets even wierder.
Do you have any idea what containers are? No clue
here...
It would seem to me that sched-rt-groups (with cgroup support) does
address the problem, but differently. SCHED_RESET_ON_FORK would prevent
the creation of a rt fork bomb, sched-rt-groups + cgroups would just
contain it within the boundaries of the maximum rt time alloted to that
group.
right. but in both cases, the remaining problem child is a clone bomb,
which in the case of RTKit requires the watchdog, whereas in the stuff
discussed at that URL is handled by the scheduler. i have to be honest
- the watchdog is the more "linux" like choice, because it puts policy
out in user space. but one could argue that for technical and
reliability reasons, the scheduler is where this really ought to be.
of course, the scheduler won't actually kill the offender, and
SCHED_RESET_ON_FORK won't either - in all likelihood, the
runaway/errant process will continue to use tons of CPU whether its
SCHED_OTHER or not. is it easier to kill a process when:
a) its SCHED_FIFO but limited to 95% of the CPU cycles
OR
b) SCHED_OTHER and competing with all other such processes
i really don't have any idea. seems as though 5% of any modern CPU
should be enough to run a shell :)