Don't know how interesting this can be, but i am writing
(no plans to commit it, unless people find it interesting)
some code to implement a weight-based instead of priority-based
scheduler. The code is basically the WF2Q+ scheme which is
already part of dummynet, adapted to processes.
It is quite compact, and i think i can make it reasonably
compatible with the old scheme, i.e. a sysctl var can be
used to switch between one and the other with reasonably
little overhead.

This would help removing the ugly property that priority-based
have, which is that one process can starve the rest of the system.


On Fri, Dec 21, 2001 at 09:07:05AM -0800, John Baldwin wrote:
> > It's whatever the thread set itself.  There is no good way of setting
> > this either (vm_pagezero() and poll_idle() hack it into
> > td->td_ksegrp->kg_pri).  Userland would use rtprio(2) instead.
> > Unfortunately, this gives priorities in different units than the ones
> > for tsleep().
> pri_level is the current priority of the thread.  The actual priority level is
> going to move back into the thread and out of the KSE group so that tsleep and
> priority propagation work properly, but pri_native, pri_user, and nice will
> stay in the KSE group.  The "normal" priorities for tsleep() are just a subset
> of the priorities available to a thread.  Thus, they are using the same unit,
> but perhaps a wider range.
> >> In any case I wonder if this is a bug new in -current; -stable
> >> uses three separate data structures for realtime, user and idle tasks
> >> so even specifying the wrong priority in tsleep should not cause
> >> crossing classes there. -current has only one array, hence the
> >> chance of doing the wrong thing.
> > 
> > The 3 classes are a design bug in -stable.  Crossing classes is sometimes
> > right and 3 classes mainly make it harder and force triplication of code.
> Agreed.  In current we basically have one large priority array.  At the top
> (low priorities) are realtime kernel priorities including interrupt thread
> priorities.  Below those are other top-half kernel priorities including the
> normal sleep priorities.  Below that are real-time user priorities, followed by
> time sharing user priorities, and finally idle user priorities.
> Possibly real-time user priorities should move up into the real-time kernel
> range, and it should be noted that the idle priorites are for idle kernel
> threads, not just user threads (so sys/priority.h may need a bit of updating).
> This is a simpler model esp. when you consider a thread of one priority class
> blocking on a lock held by a thread of a "lower" priority class as you only
> have to update pri_level for priority propagation rather than comparing classes
> and having to manage that extra gunk.
> -- 
> John Baldwin <[EMAIL PROTECTED]>  <><
> "Power Users Use the Power to Serve!"  -

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to