Messages in this thread | | | From | (Jens-Uwe Mager) | Subject | Re: [patch] O(1) scheduler-H6/H7/I0 and nice +19 | Date | 16 Jan 2002 22:41:17 GMT |
| |
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> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |