public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: "Jack O'Quin" <joq@io.com>
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 18:56:27 +1100	[thread overview]
Message-ID: <41EE12AB.9020604@kolivas.org> (raw)
In-Reply-To: <87is5tx61a.fsf@sulphur.joq.us>

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

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.

Cheers,
Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

  reply	other threads:[~2005-01-19  8:43 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 [this message]
2005-01-19 14:27     ` Jack O'Quin
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=41EE12AB.9020604@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=ck@vds.kolivas.org \
    --cc=joq@io.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox