All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Revell <rlrevell@joe-job.com>
To: "Jack O'Quin" <joq@io.com>
Cc: hihone@bigpond.net.au, Con Kolivas <kernel@kolivas.org>,
	linux <linux-kernel@vger.kernel.org>,
	CK Kernel <ck@vds.kolivas.org>,
	paul@linuxaudiosystems.com
Subject: Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt	scheduling
Date: Tue, 18 Jan 2005 21:02:01 -0500	[thread overview]
Message-ID: <1106100122.30792.23.camel@krustophenia.net> (raw)
In-Reply-To: <87d5w2u2xd.fsf@sulphur.joq.us>

On Tue, 2005-01-18 at 10:17 -0600, Jack O'Quin wrote:
> Cal <hihone@bigpond.net.au> 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.

Lee


  reply	other threads:[~2005-01-19  2:02 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 [this message]
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
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=1106100122.30792.23.camel@krustophenia.net \
    --to=rlrevell@joe-job.com \
    --cc=ck@vds.kolivas.org \
    --cc=hihone@bigpond.net.au \
    --cc=joq@io.com \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@linuxaudiosystems.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.