mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>

       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