Warner Losh <i...@harmony.village.org> writes:

> In message <199904102057.paa27...@home.dragondata.com> Kevin Day writes:
> : i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid
> : 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's
> : 40 processes get 50% cpu shared between them. 
> I've seen some experimental patches in the past that try to do just
> this.  However, there are some problems.  What if uid 1002's process
> does a sleep.  Should the 40 processes that 1001 just get 50% of the
> cpu?  Or should there be other limits.  It turns into an interesting
> research problem in a hurry.

That's a simple matter of implementation decisions.  Naturally there's
hardly ever a good reason to keep a processor idle, so the limits
should only apply when the processor would not otherwise be idle.  How
this affects the amount of runtime the processes get later depends on
how you compute percentages.

An example approach is what the class scheduling feature in Digital
UNIX does.  I'll describe it from what I remember from playing with it
a couple of years ago, so all of this is only true IIRC.  It has some
fixed scheduling period, for which it allocates cycles for that period
to scheduling classes (threads, users, groups, whatever) based on the
percentage limits.  The only addition to the scheduler is having
threads consume these cycles from the scheduling classes.  When those
cycles have been used up, threads in that class are not allowed to
run.  If an eligible processor would otherwise be idle, they may be
allowed to run despite this (the behavior is configurable in some
scope, I can't remember whether it was global or per class).

The class scheduler in Digital UNIX is, in many respects, a kludge,
and I'm not recommending that FreeBSD implement a similar mechanism.
But it is semantically "sane", and unlikely to cause additional
problems when configured with reasonable parameters.

To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Reply via email to