On Fri, Feb 8, 2008 at 11:58 AM, Igor Stasenko <siguctua at gmail.com> wrote:
> And some notes about priority.
>  I don't know much details how current squeak scheduler arranging things,
>  i'm just want to point out, that you using relative priority in your
>  samples and in your proposed patch, by writing  Processor
>  activePriority +/- n.
>  This, in own turn uncovers another problem with current scheduler
>  implementation: it's not designed to use relative priorities in mind.
>  As people pointed out:
>  Processor highestPriority + 1
>  or:
>  Processor lowestPriority -1
>  makes no sense, and lead to errors or unpredicted behavior.
>  So, first, i think, that if you really want to use relative priority
>  values, you should make changes to current implementation do to it
>  well and without errors.
>
>  Now, let's say if you make thing in the way, as i proposed in post
>  before (use highest/lowest priorities to depend only from current set
>  of running processes), the only thing which is left is to introduce a
>  scale.
>  I proposing a logarithmic time slicing:
>  a process with priority N doing roughly twice as much operations as
>  process with priority N-1 for a given period of time.

Or you could go with what I proposed quite some time back and haven't
had time to do anything about:  a real event driven preemptive
scheduler like found on the more advanced unix systems (i.e. don't
think Linux has this yet).

Quick summary:

A lot more priorities then now (the first Sun implementation had 160,
counting realtime).  Every priority level has a timeslice, the higher
the priority the smaller the timeslice.  If a process manages to use
it's whole timeslice then it gets demoted.  If it doesn't it gets
promoted.  This type of scheduler lets interactive processes always
get the CPU, and also gives CPU bound processes bigger time slices to
work with.