Andrew J. Anderson wrote:
> "quantum expiration policy" that reduces your CPU window if
> you get an involuntary context switch -- this keeps CPU hogs from choking
> the machine.
My scheduler will move a process onto a higher run-queue if it consumes
its entire timeslice without blocking, but it doesn't change the process's
timeslice length -- I'm not really sure if I should do that.
> "sleep return priority" that is generally higher than the current priorty
> (this keeps interactive performance good) -- the idea being that the
> process blocked on IO and is now ready to do something.
My scheduler does reward processes for blocking, though probably in a
slightly different way.
> "maximum wait" that defines how long a process will wait on the current
> run queue level before being escalated to a higher level. (This is how
> Solaris addresses starvation.)
I have this concept in my scheduler, but still a process is not permitted
to enjoy a higher priority than a defined minimum. It seems that this is
one gripe that people consistently have with the scheduler, and I think I
can fix it without creating big problems so I will.
> "long wait priority" that handles nice'd processes to make sure that they
> get some CPU time. This is roughly double the maximum wait by default.
>
> (The above is a very brief summary of a Hal Stern article for SunWorld,
> BTW.)
>
> Solaris also has a configurable interface into the scheduler that allows
> run-time tuning of the system. That's the icing on the cake, so to speak
> for my ideas.
'qsched' allows the user to control every scheduling parameter
"on-the-fly".
> Also, I think that Linus and crew would be more open to mucking with the
> scheduler if the patch is made as a config option, rather than a
> replacement (at least from what I've seen on the mailing list previously).
>
> I looks like the QNX patch addresses the priority levels, now it just
> needs the feedback parts, what do you think?
I think it has the basic feedback elements you mention, but does allow
starvation to happen. I'm hoping to fix that within a few weeks.
-------------------------------------------------------------------------------
Adam McKee phone: (306) 343-0881 (home)
(306) 933-1544 (work)
Programmer/Analyst (306) 956-4070 (voice-mail/pager)
SED Systems, Inc. email: amckee@poboxes.com
===============================================================================
Just say NO to IE 4.0. <http://www.sun.com/announcement/>
===============================================================================
On Mon, 16 Feb 1998, Andrew J. Anderson wrote:
> Thanks for using NetForward!
> http://www.netforward.com
> v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
>
> On Mon, 16 Feb 1998, Adam McKee wrote:
>
> > Hi there - I saw your message on the linux-kernel mailing list, and I was
> > wondering if you had comments or ideas for the QNX scheduler?
>
> I've been studying the Solaris scheduler (as much as I can w/o sources, of
> course), and the generic SYSV scheduler from which it was derived. I have
> seen articles comparing Solaris to WinNT and they showed how the Solaris
> scheduler was basically flatlined across most (all?) loads, while the NT
> scheduler operated better at low loads and lost it at high loads.
>
> Also, if you think this would be of interest to others, please forward it
> to them. I didn't cc: the kernel list because I hadn't asked you, but it
> would probably be a good idea to keep it in the loop, too.
>
> Andrew
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Andrew Anderson http://amelia.db.erau.edu/~andrew/
> if(!(family_tree=fork())){redneck=TRUE;}
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu