Re: Changing Kernel thread priorities

[Nicholas Mc Guire <der.herr@hofr.at>]

On Tue, 07 Jun 2011, Remy Bohmer wrote:

> Hi All,
> 
> 2011/6/7 Peter Zijlstra <peterz@infradead.org>:
> > On Tue, 2011-06-07 at 11:40 +0200, Armin Steinhoff wrote:
> >> Hi,
> >>
> >> when I read all these confusing statements here ( in german it looks
> >> like an "Eiertanz") ?... I can only say:
> >>
> >> - do the basic stuff in a minimal kernel driver
> >> - use UIO (or VFIO for PCI devices)
> >
> > I see no requirement for any of those horrid things to be used. You can
> > write a full on proper kernel driver, it just cannot set kernel thread
> > priorities to a sane value (let them all default to 50 or so).
> >
> > Then have a user space script or whatever set the kthread priorities.
> >> and you get clean control about your real-time priorities.
> >> I think changing the priorities of "interrupt threads" inside the kernel
> >> could lead to strange race conditions in the kernel.
> 
> Well, I 100% agree that it must be under full userspace control to be
> able to set the priorities. But, the kernel default assumption of
> starting everything at 50 is wrong as well.
> Imagine the following situation:
> * Realtime application is running and has threads active in the range
> of prios 20 - 90.
> * Now bring up a network device, it immediately starts spamming the
> system at prio 50 _before_ you have the chance to set it below 20 by
> means of chrt.
> * RT behaviour is gone!
> 
> So, in that case and in many other hotplug cases, you ruin the RT
> behaviour of the system just by the
> default-50-is-probably-right-assumption of the kernel.
> For systems where you have everything under control as a user/system
> designer, hotplug can also be under control as well.
>

I dont't quite see that - the 50 default is well dokumented so you can
plan it into the rt design at system level. It simply means that you
would need to put your hard-rt tasks in the range of 50<prio<99. 

The actual value is quite irrelevant aslong as it is well defined, and 
leaves a range free above suitably large for a rt task set (if you need
more than 5 distinct priorities for a rt task-set it generally means you
are using implicid locking any way)

I dont see the utility of adding a further interface that provides the same
level of configuration that the current user space tools do, and having one
interface for interrupt threads and one for tasks does not really simplify
things - from a rt-task-set perspective the differentiation betwen rt-tasks
and rt-related interrupt threads does not really make sens so keeping the
management in one interface seems more resonable to me.

hofrat