On Tue, 2005-01-18 at 10:17 -0600, Jack O'Quin wrote:
Cal <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
