23 Jun
2009
23 Jun
'09
8:19 p.m.
[something appears to be wrong on the list, I'm not seeing your posts
there, I'm just getting the emails directly addressed to me]
On Tue, 2009-06-23 at 16:27 -0400, Paul Davis wrote:
But is does not seem to be usable without them.
But but.. but....
For example, in the kernel I'm running (2.6.29.5 + rt21):
$ cat /proc/sys/kernel/sched_rt_period_us
1000000
$ cat /proc/sys/kernel/sched_rt_runtime_us
950000
So that part is there and configured. And:
CONFIG_CGROUP_SCHED=y
And furthermore:
CONFIG_RT_GROUP_SCHED=y
see here for an interesting entry:
https://bugzilla.redhat.com/show_bug.cgi?id=442959
and
http://bugzilla.kernel.org/show_bug.cgi?id=10361
(referenced inside the previous ticket)
this is when it was apparently added to the Fedora kernels:
--------
* Fri Apr 18 2008 Kyle McMartin <kmcmartin(a)redhat.com> -
Enable CONFIG_RT_GROUP_SCHED (#442959)
--------
There's something else I'm missing because I'm still able to run rt as a
non-root user even though I have all this stuff. Is Fedora configuring
this somewhere else? Is this overriden by something else?
If that is the case then I don't know what is the use of
SCHED_RESET_ON_FORK. I am missing something. Is a clone something harder
to do than a fork? It appears to be the same amount of programming
effort. So, if SCHED_RESET_ON_FORK works on fork and not clone, and it
is possible to make a clone bomb then SCHED_RESET_ON_FORK is worthless
(IMHO), as a clone bomb's effect would be the same as the fork bomb's
effect AFAICT and then why not deal with both using the same mechanism
rather that _adding_ something to the kernel. I definitely _have_ to be
missing something.
Ah, yes.
-- Fernando
On Tue, Jun 23, 2009 at 4:15 PM, Fernando
Lopez-Lezcano<nando(a)ccrma.stanford.edu> wrote:
I think that means that if you create a new group (whatever that is -
I'm not sure at this point) and do nothing, the member (whatever they
are) will not be able to run rt. You have to first set the root group to
something smaller and then allocate that to the new group.
On Tue, 2009-06-23 at 15:27 -0400, Paul Davis
wrote:
you are right. my initial reading was that "root group" in this
context had little to do with "root" in the traditional sense of uid=0
and more to do with "root of the filesystem" i.e. the root group is
the parent of all other cgroups. but it goes on to say "Therefore you
will not be able to run realtime tasks as any user other than root
until you have done that, even if the user has the rights to run
processes with realtime priority!"
i am also a little confused by what the default values mean (run time = 0) On Tue, Jun 23, 2009 at 2:50 PM, Fernando
Lopez-Lezcano<nando(a)ccrma.stanford.edu> wrote:
Not my reading of it. The default 100%/95% split will be allocated to
root only (the only entity - this is not a group or a cgroup - that is
there by default). My understanding is that non-root users will not be
able to run realtime unless that is changed from the default (even if
other mechanism allows them to run rt). I don't know how you enable the
whole thing in the first place.
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. The document
provides two ways of reallocating realtime real state
(configurable at build time), one by uid and the other by using
cgroup's. So, yes, you apparently depend on cgroups to get the
functionality.
true, but what i actually meant was that the measurement and limit
system is in place with or without cgroups. the API looks entirely usable to me, in the sense that
i could easily
imagine a GUI control panel for this that would be comprehensible to
most users.
I think the idea is no control panel :-)
Hmmm, did
Lennart specifically answer the issue of the clone bomb? I
can't remember and the thread is looong (I had a couple of points that I
made that seemed to be valid and never got a confirmation reply)...
i believe he claimed the watchdog deals with this. it was pointed
out that all you need to do is to know the rule the watchdog uses and
you can still pretty effectively lock the machine from the perspective
of a non-CS-y user. here's my halfway (?) summary:
"distros refuse to even provide a way to enable RLIMIT_RTPRIO because
it enables regular users to lockup the machine.
Up next: 8 other ways for regular users to easily lockup the machine ... "
Lock up a machine? As in hang it? I don't imagine it is _that_ easy. I
guess you could use up all memory and eventually get the machine
completely catatonic. And then the oom killer kicks in and something
random that uses memory dies...
I don't
know either. In either case the watchdog would probably be
running with the highest rt priority so it should be scheduled in as
fast in one as in the other. Probably faster when what needs to be
killed is SCHED_OTHER.
I don't believe that the RTKit watchdog (like Kjetil's Das Watchdog)
takes any action against any SCHED_OTHER process.