From: jum@anubis.han.de (Jens-Uwe Mager)
To: linux-kernel@vger.kernel.org
Subject: Re: [patch] O(1) scheduler-H6/H7/I0 and nice +19
Date: 16 Jan 2002 22:41:17 GMT [thread overview]
Message-ID: <slrna4c0di.at4.jum@anubis.han.de> (raw)
In-Reply-To: <mng==Pine.LNX.4.40.0201151803020.940-100000@blue1.dev.mcafeelabs.com> <mng==1011149980.8756.180.camel@phantasy>
On Wed, 16 Jan 2002 03:00:45 GMT, Robert Love <rml@tech9.net> wrote:
>On Tue, 2002-01-15 at 21:04, Davide Libenzi wrote:
>
>> On 15 Jan 2002, Robert Love wrote:
>> > This isn't a bad idea, as long as we don't use it as a crutch or
>> > excuse. That is, answer scheduling problems with "properly nice your
>> > tasks" -- the scheduler should be smart enough, to some degree.
>> >
>> > FWIW, Solaris actually implements a completely different scheduling
>> > policy, SCHED_INTERACT or something. It is for windowed tasks in X --
>> > they get a large interactivity bonus.
>
>> Now ( with 2.5.3-pre1 ) intractivity is *very good* but SCHED_INTERACT
>> would help *a lot* to get things even more right.
>
>I looked it up; its called class IA. I don't know if it grows from a
>limitation of their scheduler (i.e. they can't calculate priority and be
>as fair to interactive tasks as us) or if it offers a fundamental
>advantage. I suspect their are a myriad of things things we can do with
>an interactive/GUI scheduling policy.
>
>One thing this is, since their kernel is preemptible, it marks processes
>that very much always deserve a scheduling boost based on interactivity,
>and thus their interactivity is quite nice.
I would believe the IA class is a hack to maintain good interactive
performance for the X window apps if the scheduler does not maintain
this itself in the TS (time sharing class). The standard Solaris
scheduler is not favoring I/O bound programs properly, especially if
these are driven by network connections. I have several programs that
are of the type poll() - recv() - work a little - send() type loops and
these get slow to a crawl if run in the TS class if the foreground
process (also in TS) is compute bound.
--
Jens-Uwe Mager <pgp-mailto:62CFDB25>
next parent reply other threads:[~2002-01-16 22:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mng==Pine.LNX.4.40.0201151803020.940-100000@blue1.dev.mcafeelabs.com>
[not found] ` <mng==1011149980.8756.180.camel@phantasy>
2002-01-16 22:41 ` Jens-Uwe Mager [this message]
2002-01-15 3:27 [patch] O(1) scheduler-H6/H7 and nice +19 Davide Libenzi
2002-01-15 23:48 ` [patch] O(1) scheduler-H6/H7/I0 " Ed Tomlinson
2002-01-15 23:56 ` Davide Libenzi
2002-01-16 1:49 ` Ingo Molnar
2002-01-16 0:44 ` Ed Tomlinson
2002-01-16 2:06 ` Rene Rebe
2002-01-16 2:48 ` Ingo Molnar
2002-01-16 1:59 ` Robert Love
2002-01-16 2:04 ` Davide Libenzi
2002-01-16 2:59 ` Robert Love
2002-01-16 3:04 ` Linus Torvalds
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=slrna4c0di.at4.jum@anubis.han.de \
--to=jum@anubis.han.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 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.