Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged softrt scheduling

[Con Kolivas]

Lee Revell wrote:
> On Tue, 2005-01-18 at 10:17 -0600, Jack O'Quin wrote:
>
> > Cal <hihone@xxxxxxxxxxxxxx> writes:
> >
> >
> > > There's a collection of test summaries from jack_test3.2 runs at
> > > <http://www.graggrag.com/ck-tests/ck-tests-0501182249.txt>
> > >
> > > Tests were run with iso_cpu at 70, 90, 99, 100, each test was run
> > > twice. The discrepancies between consecutive runs (with same
> > > parameters) is puzzling.  Also recorded were tests with SCHED_FIFO and
> > > SCHED_RR.
> >
> > It's probably suffering from some of the same problems of thread
> > granularity we saw running nice --20.  It looks like you used
> > schedtool to start jackd.  IIUC, that will cause all jackd processes
> > to run in the specified scheduling class.  JACK is carefully written
> > not to do that.  Did you also use schedtool to start all the clients?
> >
> > I think your puzzling discrepancies are probably due to interference
> > from non-realtime JACK threads running at elevated priority.
>
>
> Isn't this going to be a showstopper?  If I understand the scheduler
> correctly, a nice -20 task is not guaranteed to preempt a nice -19 task,
> if the scheduler decides that one is more CPU bound than the other and
> lowers its dynamic priority.  The design of JACK, however, requires the
> higher priority threads to *always* preempt the lower ones.

The point was the application was started in a manner which would not 
make best use of this policy. The way it was started put everything 
under the same policy, and had equal performance with doing the same 
thing as SCHED_FIFO. So if it's a showstopper for SCHED_ISO then it is a 
showstopper for SCHED_FIFO. Which is, of course, not the case. The test 
needs to be performed again with the rt threads running SCHED_ISO, which 
 Jack has pointed out is trivial. Nice -n -20 on the other hand will 
suffer from this problem even if only the real time thread was run at -20.

Cheers,
Con
-
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/