linux-kernel.vger.kernel.org archive mirror
 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 10:18:25 +0200	[thread overview]
Message-ID: <3EFBFDD1.4000603@aitel.hist.no> (raw)
In-Reply-To: 5.2.0.9.2.20030627071904.00c890e0@pop.gmx.net

Mike Galbraith wrote:

> The thought of building/passing "connection" information around in the 
> scheduler gives me a bad case of the willies.  I can imagine a process 
> struct containing a list of components and their cpu usage information 
> as a means to defeat fairness/starvation issues, but I can't imagine how 
> to do that and retain high speed low drag O(1) scheduling.
> 
The idea isn't that complicated.  When a process wakes up, make
a simple check to see what it woke up from.  Ordinary
io is handled as today, with a io boost.

A pipe wakeup can be handled by taking a look at the other end.
If the other process has interactivity bonus, grab half of
it.  (And halve the bonus belonging to that process.)
No bonus is created in this case, so no risk of DOS.
It is merely redistributed.

And it is simple - there is one thing that woke the
process up - so only one thing to check.

Hard corner cases can be avoided.  Perhaps bunch of pipes,
files, devices, sockets and page-ins becomes ready
simultaneosly.  A detailed priority calculation is clearly
pointless, so just use one of the things - or none.

> Until someone demonstrates that the DoS/abuse scenarios I might be 
> imagining are real, in C, I think I'll do the smart thing: try to stop 
> worrying about it and stick to very very simple stuff.

I thought the Irman thing was what killed the previous attempt
at redistributing priorities?

Helge Hafting


  reply	other threads:[~2003-06-27  7:58 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 [this message]
2003-06-27  9:46                 ` Mike Galbraith
2003-06-27 11:39                   ` Helge Hafting
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
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=3EFBFDD1.4000603@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;
as well as URLs for NNTP newsgroup(s).