Re: Likelihood of rt_tasks

[Con Kolivas]

Peter Williams wrote:
> 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).

Well I dont think making them unlikely is necessary either, but 
realistically the amount of time added by the unlikely() check will be 
immeasurably small in real terms - and hitting it frequently enough will 
be washed over by the cpu as Ingo said. I dont think the order of 
magnitude of this change is in the same universe as the problem of 
scheduling latency that people are complaining of.

Con

Attachment: signature.asc
Description: OpenPGP digital signature