Re: Likelihood of rt_tasks

[Elladan <elladan@eskimo.com>]

On Sat, Jul 10, 2004 at 09:53:22AM +1000, Peter Williams wrote:
> Con Kolivas wrote:
>
> >While rt tasks are normally unlikely, what happens in the case when you 
> >are scheduling one or many running rt_tasks and the majority of your 
> >scheduling is rt? Would it be such a good idea in this setting that it 
> >is always hitting the slow path of branching all the time?
> 
> Even when this isn't the case you don't want to make all rt_task() 
> checks "unlikely".  In particular, during "wake up" using "unlikely" 
> around rt_task() will increase the time that it takes for SCHED_FIFO 
> tasks to get onto the CPU when they wake which will be bad for latency 
> (which is generally important to these tasks as evidenced by several 
> threads on the topic).

Average wall speed of RT task wakeup isn't really an issue - the issue
is deterministic worst-case latency.  Adding a hundred cycles every time
won't cause someone to miss a deadline.  The deadlines need to be based
on the worst case, where the cache is 100% cold and you're at the
beginning of a long-held mutex section etc.

An unlikely branch won't have any measurable effect on worst-case wakeup
latency, but will reduce the average impact of the test on the common
fast path for normal processes.

I don't see how this is anything but a good idea.

-J