On Tue, Jun 23, 2009 at 2:50 PM, Fernando
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...
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
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 :)
Linux-audio-dev mailing list