public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Helge Hafting <helgehaf@aitel.hist.no>
To: Mike Galbraith <efault@gmx.de>
Cc: Bill Davidsen <davidsen@tmr.com>, linux-kernel@vger.kernel.org
Subject: Re: O(1) scheduler & interactivity improvements
Date: Fri, 27 Jun 2003 13:39:52 +0200	[thread overview]
Message-ID: <3EFC2D08.6000905@aitel.hist.no> (raw)
In-Reply-To: 5.2.0.9.2.20030627110106.00cf6068@pop.gmx.net

Mike Galbraith wrote:
> At 10:18 AM 6/27/2003 +0200, Helge Hafting wrote:
> 
[...]

 > (simple?  decode stack, find out where he was sleeping,
Complicated indeed, but why do that?
A process sleeping on a pipe will wake up in the kernel's
pipe reading code, won't it?  No need for guessing where
it was sleeping.  Code for transferring interactivity
bonus could go right there.

> 
> What I think kills the priority redistribution idea is _massive_ 
> complexity.  I don't see anything simple.  You would have to build the 
> logical connections between tasks, which currently doesn't exist.  

I must admit I don't know the details of the scheduler.  Still, Linus
tried a form of redistribution (the backboost thing).  It helped in some 
cases.
It seems to me that it got revoked because it did the wrong
thing at times, leading to starvation issus that didn't exist before.
It didn't go because it was overly complex or slow?

Helge Hafting

> Wakeups and task switches are extremely light weight operations, and no 
> decision you make at wakeup time has a ghost of a chance of not hurting 
> like hell.  Just using the monotonic_clock() in the wakeup/schedule 
> paths is fairly painful.  There is just no way you can run around 
> looking for and processing "who shot JR" information in those paths (no 
> way _I_ can imagine anyway) without absolutely destroying performance.
> 


  reply	other threads:[~2003-06-27 11:19 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-22 16:07 O(1) scheduler & interactivity improvements Felipe Alfaro Solana
2003-06-22 20:00 ` Davide Libenzi
2003-06-23 12:50   ` Jesse Pollard
2003-06-23  8:09 ` Helge Hafting
2003-06-23 10:18   ` Felipe Alfaro Solana
2003-06-23 16:21     ` Daniel Gryniewicz
2003-06-23 18:59       ` Felipe Alfaro Solana
2003-06-23 19:21         ` Memory? " Roger Larsson
2003-06-23 16:47     ` Helge Hafting
2003-06-24 18:12       ` Bill Davidsen
2003-06-25 21:41         ` Helge Hafting
     [not found]       ` <5.2.0.9.2.20030624215008.00ce73b8@pop.gmx.net>
2003-06-26  9:59         ` Helge Hafting
2003-06-26 10:39           ` Mike Galbraith
2003-06-26 14:50           ` Bill Davidsen
2003-06-26 23:10           ` Timothy Miller
     [not found]           ` <Pine.LNX.3.96.1030626104733.17562D-100000@gatekeeper.tmr.c om>
2003-06-27  6:36             ` Mike Galbraith
2003-06-27  8:18               ` Helge Hafting
2003-06-27  9:46                 ` Mike Galbraith
2003-06-27 11:39                   ` Helge Hafting [this message]
2003-06-27 12:18                     ` Mike Galbraith
2003-06-28  3:51                   ` Bill Davidsen
     [not found]                   ` <Pine.LNX.3.96.1030627234408.25848A-100000@gatekeeper.tmr.c om>
2003-06-28  5:44                     ` Mike Galbraith
2003-06-28 14:34                       ` Helge Hafting
2003-06-29  6:08                         ` Mike Galbraith
2003-06-30 13:37                       ` Bill Davidsen
2003-06-27  6:54           ` jw schultz
  -- strict thread matches above, loose matches on Subject: below --
2003-06-23 10:50 John Bradford
2003-06-23 11:22 ` Felipe Alfaro Solana
2003-06-23 11:36 ` Denis Vlasenko
2003-06-23 12:44 John Bradford
2003-06-23 16:32 ` Helge Hafting
2003-06-23 19:00   ` Felipe Alfaro Solana
2003-06-23 19:17     ` Helge Hafting
2003-06-24 22:41   ` Timothy Miller
2003-06-25 21:42     ` Helge Hafting
2003-06-25 23:16       ` Timothy Miller
2003-06-23 21:48 ` Bill Davidsen
2003-06-23 19:20 John Bradford
2003-06-23 23:32 John Bradford
2003-06-24  4:13 ` Bill Davidsen

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=3EFC2D08.6000905@aitel.hist.no \
    --to=helgehaf@aitel.hist.no \
    --cc=davidsen@tmr.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.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