All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Kumlien <pomac@vapor.com>
To: Robert Love <rml@tech9.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [SHED] Questions.
Date: Mon, 01 Sep 2003 00:41:25 +0200	[thread overview]
Message-ID: <1062369684.9959.166.camel@big.pomac.com> (raw)
In-Reply-To: <1062359478.1313.9.camel@boobies.awol.org>

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

On Sun, 2003-08-31 at 21:51, Robert Love wrote:
> On Sun, 2003-08-31 at 15:31, Ian Kumlien wrote:
> 
> > Since they would have a high pri still, and preempt is there... it
> > should be back on the cpu pretty quick.
> 
> Ah, but no!  You assume we do not have an expired list and round robin
> scheduling.

hummm, I assume that a high pri process can preempt a low pri process...
The rest sounds sane to me =), Please tell me what i'm missing.. =)

> Once a task exhausts its timeslice, it cannot run until all other tasks
> exhaust their timeslice.  If this were not the case, high priority tasks
> could monopolize the system.

All other? including sleeping?... How many tasks can be assumed to run
on the cpu at a time?....

Should preempt send the new quantum value to all "low pri, high quantum"
processes?

Damn thats a tough cookie, i still think that the priority inversion is
bad. Don't know enough about this to actually provide a solution... 
Any one else that has a view point?

> > But, it also creates problems for when a interactive process becomes a
> > cpu hog. Like this the detection should be faster, but should be slowed
> > down somewhat.
> 
> I agree, although I do think it responds fairly quick.  But, regardless,
> this is why I am interested in Nick's work.  The interactivity estimator
> can never be perfect.

Hummm, the skips in xmms tells me that something is bad.. 
(esp since it works perfectly on the previus scheduler)

> > But, hogs would instead cause a context switch hell and lessen the
> > throughput on server loads...
> 
> Hm, why?

Since it's rescheduled after a short runtime or, might be.
From someones mail i saw (afair), there was much more context switches
in 2.6 than in 2.4. And each schedule consumes time and cycles.

> > I don't see how priorities would be questioned... Since, all i say is
> > that a task that gets preempted should have a guaranteed time on the cpu
> > so that we don't waste cycles doing context switches all the time. 
> 
> But latency is important.

Oh yes, but otoh, if you are really keen on the latency then you'll do
realtime =)

-- 
Ian Kumlien <pomac@vapor.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2003-08-31 22:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-31 10:07 [SHED] Questions Ian Kumlien
2003-08-31 10:17 ` Nick Piggin
2003-08-31 10:24   ` Ian Kumlien
2003-08-31 10:41     ` Nick Piggin
2003-08-31 10:46       ` Nick Piggin
     [not found]       ` <1062326980.9959.65.camel@big.pomac.com>
     [not found]         ` <3F51D4A4.4090501@cyberone.com.au>
2003-08-31 11:08           ` Ian Kumlien
2003-08-31 11:31             ` Nick Piggin
2003-08-31 11:43               ` Ian Kumlien
2003-08-31 18:53 ` Robert Love
2003-08-31 19:31   ` Ian Kumlien
2003-08-31 19:51     ` Robert Love
2003-08-31 22:41       ` Ian Kumlien [this message]
2003-08-31 23:41         ` Robert Love
2003-09-01  0:00           ` Ian Kumlien
2003-09-01  2:50             ` Con Kolivas
2003-09-01 15:58               ` Antonio Vargas
2003-09-01 22:19               ` Ian Kumlien
2003-09-01  4:03             ` Robert Love
2003-09-01  5:07               ` Con Kolivas
2003-09-01  5:55                 ` Robert Love
2003-09-01 22:24               ` Ian Kumlien
2003-09-01 14:21             ` Antonio Vargas
2003-09-01 19:36               ` Geert Uytterhoeven
2003-09-01 22:49               ` Ian Kumlien
2003-09-01 15:07           ` Daniel Phillips
2003-09-01 14:16             ` Antonio Vargas
2003-09-01 23:03             ` Ian Kumlien
2003-09-02  0:04               ` Nick Piggin
2003-09-02  0:23               ` Con Kolivas
2003-09-02 10:25                 ` Ian Kumlien
2003-09-02 11:08                   ` Nick Piggin
2003-09-02 17:22                     ` Ian Kumlien
2003-09-02 23:49                       ` Nick Piggin
2003-09-03 23:02                         ` Ian Kumlien
2003-09-04  1:39                           ` Mike Fedyk
2003-09-02 10:44                 ` Wes Janzen

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=1062369684.9959.166.camel@big.pomac.com \
    --to=pomac@vapor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@tech9.net \
    /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.