From: Peter Williams <pwil3058@bigpond.net.au>
To: Mike Galbraith <efault@gmx.de>
Cc: Con Kolivas <kernel@kolivas.org>,
Rene Herman <rene.herman@keyaccess.nl>,
Lee Revell <rlrevell@joe-job.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: 2.6.17-rc2+ regression -- audio skipping
Date: Mon, 22 May 2006 15:38:23 +1000 [thread overview]
Message-ID: <44714E4F.8000801@bigpond.net.au> (raw)
In-Reply-To: <1148273580.9914.3.camel@homer>
Mike Galbraith wrote:
> On Mon, 2006-05-22 at 13:30 +1000, Peter Williams wrote:
>> What about the batch tasks? How do you ensure that they don't get
>> starved? Remember they're "batch" tasks not "background" tasks.
>>
>
> Here, batch means background. To make them batch as in only static
> priority, I'd just do away with the second array. Batch as background
> makes more sense to me, and since it's my ball and my playground... ;-)
>
In reality, both batch and background are useful distinct concepts. I
think of a batch task as one that needs to be treated fairly (in
accordance with its nice value) but for which fairness shouldn't be
broken to give it a boost as you might for an interactive task or media
streamer. I.e. doing useful work but not interactive or a media
streamer and the occasional long latency isn't a disaster.
Background tasks are ones where you don't care if they ever get any cpu
:-) except as necessary to prevent priority inversion.
In my schedulers I generalize background to "soft cpu rate caps" with a
cap of zero being the same as background. I have patches to add both
soft and hard cpu rate caps to the standard scheduler but I'm sitting on
them until things settle down a bit.
Anyway, schedulers based on single priority arrays (such as staircase)
are looking more attractive every day. :-)
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
next prev parent reply other threads:[~2006-05-22 5:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-21 20:24 2.6.17-rc2+ regression -- audio skipping Rene Herman
2006-05-21 21:30 ` Lee Revell
2006-05-22 0:10 ` Rene Herman
2006-05-22 0:17 ` Rene Herman
2006-05-22 0:33 ` Con Kolivas
2006-05-22 2:14 ` Mike Galbraith
2006-05-22 2:43 ` Con Kolivas
2006-05-22 3:10 ` Mike Galbraith
2006-05-22 3:30 ` Peter Williams
2006-05-22 4:53 ` Mike Galbraith
2006-05-22 5:38 ` Peter Williams [this message]
2006-05-22 6:00 ` Mike Galbraith
2006-05-22 6:34 ` Peter Williams
2006-05-23 5:22 ` Peter Williams
2006-05-22 3:26 ` Peter Williams
2006-05-22 18:22 ` Rene Herman
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=44714E4F.8000801@bigpond.net.au \
--to=pwil3058@bigpond.net.au \
--cc=efault@gmx.de \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rene.herman@keyaccess.nl \
--cc=rlrevell@joe-job.com \
--cc=torvalds@osdl.org \
/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