public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 13:30:39 +1000	[thread overview]
Message-ID: <4471305F.40105@bigpond.net.au> (raw)
In-Reply-To: <1148267426.21765.15.camel@homer>

Mike Galbraith wrote:
> On Mon, 2006-05-22 at 12:43 +1000, Con Kolivas wrote:
>> On Monday 22 May 2006 12:14, Mike Galbraith wrote:
>>> In my tree, I don't use the expired array for anything except batch
>>> tasks any more for this very reason. The latency just hurts too bad.
>> So it's turning your tree into a single priority array design effectively just 
>> like staircase ;) ?
> 
> Similar I suppose.  I still do have dual arrays though, because it's an
> almost free way to deal with batch tasks (and is now named accordingly).
> 
> I also still use sleep_avg, but I keep it sane, and with the full
> dynamic spread instead of gravitating to either full or empty, and I
> monitor for cpu hungry tasks, and let them climb the ladder to where the
> action is.  That way, it retains the pleasant interactivity of the
> current design, yet is absolutely starvation proof.

What about the batch tasks?  How do you ensure that they don't get 
starved?  Remember they're "batch" tasks not "background" tasks.

Do you force an array switch after a while and if so how do you handle 
the adverse effects that will have on any non batch tasks on the other 
queue?

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

  reply	other threads:[~2006-05-22  3:30 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 [this message]
2006-05-22  4:53               ` Mike Galbraith
2006-05-22  5:38                 ` Peter Williams
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=4471305F.40105@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