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.
next prev parent 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.