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 " 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: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
2002-01-16 2:06 ` Rene Rebe
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome