Re: Likelihood of rt_tasks

[Peter Williams <pwil3058@bigpond.net.au>]

Con Kolivas wrote:
> A quick question about the usefulness of making rt_task() checks 
> unlikely in sched-unlikely-rt_task.patch which is in -mm
> 
> quote:
> 
> diff -puN include/linux/sched.h~sched-unlikely-rt_task 
> include/linux/sched.h
> --- 25/include/linux/sched.h~sched-unlikely-rt_task    Fri Jul  2 
> 16:33:01 2004
> +++ 25-akpm/include/linux/sched.h    Fri Jul  2 16:33:01 2004
> @@ -300,7 +300,7 @@ struct signal_struct {
> 
>  #define MAX_PRIO        (MAX_RT_PRIO + 40)
> 
> -#define rt_task(p)        ((p)->prio < MAX_RT_PRIO)
> +#define rt_task(p)        (unlikely((p)->prio < MAX_RT_PRIO))
> 
>  /*
>   * Some day this will be a full-fledged user tracking system..
> 
> ---
> 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).

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce