From: "Jack O'Quin" <joq@io.com>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
rlrevell@joe-job.com, paul@linuxaudiosystems.com,
CK Kernel <ck@vds.kolivas.org>
Subject: Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
Date: Wed, 19 Jan 2005 08:27:48 -0600 [thread overview]
Message-ID: <87y8eptrx7.fsf@sulphur.joq.us> (raw)
In-Reply-To: <41EE12AB.9020604@kolivas.org> (Con Kolivas's message of "Wed, 19 Jan 2005 18:56:27 +1100")
Con Kolivas <kernel@kolivas.org> writes:
> Jack O'Quin wrote:
>> Con Kolivas <kernel@kolivas.org> writes:
>>
>>>This patch for 2.6.11-rc1 provides a method of providing real time
>>>scheduling to unprivileged users which increasingly is desired for
>>>multimedia workloads.
>> I ran some jack_test3.2 runs with this, using all the default
>> settings. The results of three runs differ quite significantly for no
>> obvious reason. I can't figure out why the DSP load should vary so
>> much. These may be bogus results. It looks like a libjack bug
>> sometimes
>> causes clients to crash when deactivating. I will investigate more
>> tomorrow, and come up with a fix.
>> For comparison, I also made a couple of runs using the realtime-lsm
>> to
>> grant SCHED_FIFO privileges. There was some variablility, but nowhere
>> near as much (and no crashes). I used schedtool to verify that the
>> jackd threads actually have the expected scheduler type.
>
> Thanks for those. If you don't know what to make of the dsp variation
> and the crashing then I'm not sure what I should make of it
> either. It's highly likely that my code still needs fixing to ensure
> it behaves as expected. Already one bug has been picked up in testing
> with respect to yield() so there may be others. By design, if you set
> iso_cpu to 100 it should be as good as SCHED_RR. If not, then the
> implementation is still buggy.
I fixed that bug in libjack, eliminating the crashes on disconnect.
They must have been perturbing the numbers quite a bit. Here are
three more runs (all SCHED_ISO). The results are much more
consistent. The only significant anomaly I see now is that small
Delay Max in the first run.
*** Terminated Wed Jan 19 01:04:55 CST 2005 ***
************* SUMMARY RESULT ****************
Total seconds ran . . . . . . : 300
Number of clients . . . . . . : 20
Ports per client . . . . . . : 4
Frames per buffer . . . . . . : 64
*********************************************
Timeout Count . . . . . . . . :( 1) ( 5) ( 3)
XRUN Count . . . . . . . . . : 2 16 15
Delay Count (>spare time) . . : 0 0 0
Delay Count (>1000 usecs) . . : 0 0 0
Delay Maximum . . . . . . . . : 11932 usecs 101053 usecs 98719 usecs
Cycle Maximum . . . . . . . . : 868 usecs 1099 usecs 887 usecs
Average DSP Load. . . . . . . : 37.9 % 33.6 % 36.0 %
Average CPU System Load . . . : 10.2 % 9.0 % 9.9 %
Average CPU User Load . . . . : 24.5 % 22.7 % 23.0 %
Average CPU Nice Load . . . . : 0.0 % 0.0 % 0.0 %
Average CPU I/O Wait Load . . : 0.6 % 3.4 % 0.4 %
Average CPU IRQ Load . . . . : 0.7 % 0.7 % 0.7 %
Average CPU Soft-IRQ Load . . : 0.0 % 0.0 % 0.0 %
Average Interrupt Rate . . . : 1688.1 /sec 1696.1 /sec 1685.2 /sec
Average Context-Switch Rate . : 11727.9 /sec 10642.4 /sec 11568.3 /sec
*********************************************
I should probably experiment with higher thresholds on the SCHED_ISO class.
--
joq
next prev parent reply other threads:[~2005-01-19 14:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-18 13:01 [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling Con Kolivas
2005-01-18 14:53 ` Con Kolivas
2005-01-18 15:45 ` [ck] " Cal
2005-01-18 15:53 ` Con Kolivas
2005-01-18 16:23 ` Jack O'Quin
2005-01-18 16:17 ` Jack O'Quin
2005-01-19 2:02 ` Lee Revell
2005-01-19 2:08 ` Con Kolivas
2005-01-19 5:26 ` utz
2005-01-19 5:31 ` Con Kolivas
2005-01-19 14:01 ` Con Kolivas
2005-01-19 6:54 ` Jack O'Quin
2005-01-19 7:56 ` Con Kolivas
2005-01-19 14:27 ` Jack O'Quin [this message]
2005-01-19 9:33 ` Con Kolivas
2005-01-19 17:12 ` Jack O'Quin
2005-01-20 0:07 ` Con Kolivas
2005-01-20 1:21 ` Jack O'Quin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y8eptrx7.fsf@sulphur.joq.us \
--to=joq@io.com \
--cc=ck@vds.kolivas.org \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paul@linuxaudiosystems.com \
--cc=rlrevell@joe-job.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.