Re: Likelihood of rt_tasks

[Peter Williams]

Con Kolivas wrote:
> 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,

No, just leave them unadorned.  I.e. the aim would just be to avoid the 
penalty of being on the "unlikely" path not to get special treatment.

> but 
> realistically the amount of time added by the unlikely() check will be 
> immeasurably small in real terms

It's not the time taken to do the check that's the issue. 
Unlikely/likely come with the warning that the "unlikely" path will take 
longer than it would otherwise have taken and consequently should only 
be used when you're pretty confident that your assessment of the 
likelihood is correct AND you're willing to pay a time penalty on the 
"unlikely" path whenever it is chosen.  My point is that I think that 
that penalty is unacceptable during "wake up".

> - 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.

They are talking very small times.

Peter
--
Peter Williams                                   pwil3058@xxxxxxxxxxxxxx

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/