On Wed, 16 Jan 2002 03:00:45 GMT, Robert Love <[email protected]> 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>