All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.