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

Mike Galbraith
2005-01-15T08:18:37Z

At 07:14 PM 1/14/2005 -0600, Jack O'Quin wrote:
>Mike Galbraith <efault@gmx.de> 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