Re: [PATCH] [request for inclusion] Realtime LSM

[Mike Galbraith <efault@xxxxxx>]

At 07:14 PM 1/14/2005 -0600, Jack O'Quin wrote:
> Mike Galbraith <efault@xxxxxx> writes:
>
> > At 05:31 PM 1/13/2005 -0600, Jack O'Quin wrote:
> >>Yes.  However, my tests have so far shown a need for "actual FIFO as
> >>long as the task behaves itself."
> >
> > I for one wonder why that appears to be so.  What happens if you use
> > SCHED_RR instead of SCHED_FIFO?
> >
> > (ie is the problem just one of running out of slice at a bad time, or
> > is it the dynamic priority adjustment)
>
> I have no quick and easy test for that.
>
> If it's important, I can modify a version of JACK to use SCHED_RR,
> instead.

I think the problem you're seeing is strange enough to consider trying the 
(possibly odd sounding) test.  I haven't seen an explanation of why nice 
-20 doesn't work for you.

> I very much doubt it would make any difference, since we normally only
> run one realtime thread at a time.  Each client taps the next on the
> shoulder when it is time for it to run, so there is essentially no
> concurrency among them.

It may not make any difference.  Seeing that would at least be an 
additional datapoint.  The only significant difference I see between a 
gaggle of SCHED_FIFO tasks and one of nice -20 tasks, who are alone in 
their top-of-the-heap queue, and who are not cpu hogs, is the timeslice.  I 
don't recall there being any wakeup/preempt logic differences, ergo the 
SCHED_RR suggestion.

        -Mike 

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