Re: [PATCH] kthread: always create the kernel threads with normal priority

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]


On Mon, 2008-01-07 at 09:29 -0800, Andrew Morton wrote:
> On Mon, 7 Jan 2008 12:09:04 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > > > This causes a practical problem. When a runaway real-time task is 
> > > > eating 100% CPU and we attempt to put the CPU offline, sometimes we 
> > > > block while waiting for the creation of the highest-priority 
> > > > "kstopmachine" thread.
> > 
> > sched-devel.git has new mechanisms against runaway RT tasks. There's a 
> > new RLIMIT_RTTIME rlimit - if an RT task exceeds that rlimit then it is 
> > sent SIGXCPU.
> 
> Is that "total RT CPU time" or "elapsed time since last schedule()"?
> 
> If the former, it is not useful for this problem.
> 
> > there's also a new group scheduling extension that is driven via a 
> > sysctl:
> > 
> >   /proc/sys/kernel/sched_rt_ratio
> > 
> > this way if a user has a runaway RT task, other users (and root) will 
> > still have some CPU time left. (in Peter's latest patchset that is 
> > replaced via rt_runtime_ns - but this is a detail)
> 
> Doesn't this make the RT task non-RT?  Would need to understand more
> details to tell.

Its an artifact of rt group scheduling. Each group will have to specify
a period and runtime limit therein (and the normalized sum thereof must
not exceed the total time available - otherwise the set is not
schedulable).

So say we have two groups A and B. A has a period of 2 seconds and a
runtime limit of 1, that gives him an avg of 50% cpu time. If B then has
a period of 1 second with a runtime limit of .25s (avg 25%) the total
time required to schedule the realtime groups would be 75% on average.

Without group scheduling everything is considered one group but we still
have the period and runtime limits.

So as long as the realtime cpu usage fits within the given limits it
acts as before. Once it exceeds its limit it will be capped hard - which
is ok, since it exceeded its hard limit, and realtime applications are
supposed to be deterministic and thus be able to tell how much time
they'd require. [ If only this model were true, but its a model
frequently used and quite accepted ]



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]