All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: Mike Galbraith <efault@gmx.de>
Cc: Mike Fedyk <mfedyk@matchmail.com>,
	John Yau <jyau_kernel_dev@hotmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Priority Inversion in Scheduling
Date: Wed, 10 Sep 2003 19:28:58 +1000	[thread overview]
Message-ID: <3F5EEEDA.7070406@cyberone.com.au> (raw)
In-Reply-To: <6.0.0.22.0.20030910074121.01c8a220@pop.gmx.net>



Mike Galbraith wrote:

> At 07:35 AM 9/10/2003, Mike Fedyk wrote:
>
>> On Wed, Sep 10, 2003 at 06:42:10AM +0200, Mike Galbraith wrote:
>> > At 02:23 AM 9/10/2003, Nick Piggin wrote:
>> > >Hi John,
>> > >Your mechanism is basically "backboost". Its how you get X to keep a
>> > >high piroirity, but quite unpredictable. Giving a boost to a process
>> > >holding a semaphore is an interesting idea, but it doesn't address 
>> the
>> > >X problem.
>> >
>> > FWIW, I tried the hardware usage bonus thing, and it does cure the X
>> > inversion problem (yeah,  it's a pretty cheezy way to do it).  It also
>> > cures xmms skips if you can't get to the top without hw usage.  I also
>> > tried a cpu limited backboost from/to tasks associated with 
>> hardware, and
>> > it hasn't run amok... yet ;-)
>>
>> Against which scheduler, and when are you going to post the patch?
>
>
> Against stock test-4, but I'm not going to post it.  It's just an 
> experiment to verify that there is another simple way to defeat the X 
> inversion problem (while retaining active list requeue).  Also, 
> backboost is a tricky little bugger, and I thought I'd let Nick know 
> that I had some success with this heavily restricted form.  (global 
> backboost can be down right evil)
>
> If anyone having inversion or concurrency troubles wants to give it a 
> try for grins, they can drop me a line.  My tree tends to morph a lot 
> though, depending on what aspect of scheduling I'm tinkering with at 
> the time.  It currently does well at defeating known starvation 
> issues, but I don't like it's priority distribution much (and it's not 
> destined for inclusion, and it's pretty darn ugly, and I'll likely 
> break it all to pieces again soon, and...;).


Sounds interesting. I my scheduler doesn't have any inversion or
starvation issues that I know of without backboost though. I'd like to
know if you find any.



  reply	other threads:[~2003-09-10  9:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-09 19:57 Priority Inversion in Scheduling John Yau
2003-09-10  0:23 ` Nick Piggin
2003-09-10  4:42   ` Mike Galbraith
2003-09-10  5:35     ` Mike Fedyk
2003-09-10  6:22       ` Mike Galbraith
2003-09-10  9:28         ` Nick Piggin [this message]
2003-09-10 10:47           ` Mike Galbraith
  -- strict thread matches above, loose matches on Subject: below --
2003-09-10  2:20 John Yau
2003-09-10  2:31 ` Nick Piggin
2003-09-10  5:41   ` Priority Inversion in Scheduling John Yau

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=3F5EEEDA.7070406@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=efault@gmx.de \
    --cc=jyau_kernel_dev@hotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.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.