From: Ian Kumlien <pomac@vapor.com>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [SHED] Questions.
Date: Sun, 31 Aug 2003 13:43:28 +0200 [thread overview]
Message-ID: <1062330208.9959.87.camel@big.pomac.com> (raw)
In-Reply-To: <3F51DC86.8040800@cyberone.com.au>
[-- Attachment #1: Type: text/plain, Size: 3579 bytes --]
On Sun, 2003-08-31 at 13:31, Nick Piggin wrote:
> Ian Kumlien wrote:
>
> >[Forgot to CC LKML last time, so i didn't remove old text ]
> >
> >On Sun, 2003-08-31 at 12:57, Nick Piggin wrote:
> >
> >
> >>Heh, well we discuss stuff sometimes, but we disagree on things.
> >>Which is a good thing because now our eggs are in two baskets.
> >>
> >
> >Yes, but sometimes it feels like a merger would be better... As long as
> >the propper quantum usage prevails =)
> Nope. They're going in different directions. We'd slow each other down.
Okis.
> >>Yeah quite a lot. Lots included removing the interactivity stuff.
> >>
> >
> >Humm, yeah, that should work automatically with the "used the full
> >quantum" if thats still in that is... =)
> >
>
> You've lost me here.
> My stuff is the opposite of what the interactivity stuff is trying
> to do. The interactivity stuff _does_ kind of implement variable
> timeslices in the form of re queueing stuff. I think it would be a
> nightmare for them to put my variable timeslices on top of that and
> then get it to all work properly.
Well, i dunno how your patch works (i forget =))... But afair ingos
interactivity patches was about the amount of the quantum that was used.
And combining that with high = small and low = large would automatically
balance the priorities accordingly.
> >>Yeah it is, but the process will still take a lot of the penalty,
> >>and if it is using a lot of CPU in context switching, then it will
> >>get a lower priority anyway. Possibly there could be a very small
> >>additional penalty per context switch, but so far it hasn't been
> >>a big problem AFAIK.
> >>
> >
> >Well my idea was more... The highest pri gets MIN_QUANT and a preemt
> >can't happen faster than MIN_QUANT or so..
> >
>
> My idea is to try to make it as simple as possible, and no
> simpler (as a great man put it!). So more is less if you
> know what I mean.
Yup =)
> I think this is going against how the scheduler (and UNIX
> schedulers in general) have generally behaved. Its very likely
> that you'd be better off fixing your app / other broken bit
> of kernel code though.
>
> I don't know... maybe...
Humm i thought more in the direction of:
Preempt prior to MIN_QUANT being used -> put it on the runqueue as the
next process being scheduled, change the running tasks timeslice ->
continue with current task.
(make the current tasks timeslice appear as used.)
> >If i remember correctly, 2.6 spends much more time doing the actual
> >context switches (not time / context switch but amount during this
> >period). The new 1000 HZ thingy doesn't have to have that effect...
> >
> >And since to many context switches are inefficient imho, some standoffs
> >would be good =)
> >
>
> I'm not sure. I think the 1000HZ thing is mainly from timer interrupts.
> The scheduler should be pretty well agnostic to the 100->1000 change,
> other than having higher resolution. Increased context switches might
> indicate something is not being scaled with HZ properly though.
hummm i dunno, but afair the scheduler uses that timing aswell...
> Yes context switches are inefficient. The tradeoff is vs scheduling
> latency and there is no way around that.
Thus, keeping preempt from being able to preempt other tasks prior to
MIN_QUANT being used is bad.. =)
Which also might fix the "child preempting parent on fork" problem that
con patched afair.
(dunno if you have the same problem though...)
--
Ian Kumlien <pomac@vapor.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-08-31 11:44 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 [this message]
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
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=1062330208.9959.87.camel@big.pomac.com \
--to=pomac@vapor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.com.au \
/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).