Brian Feldman 226f14bc83 Change the scheduler to actually respect the PUSER barrier. It's been
wrong for many years that negative niceness would lower the priority
of a process below PUSER, and once below PUSER, there were conditionals
in the code that are required to test for whether a process was in
the kernel which would break.

The breakage could (and did) cause lock-ups, basically nothing else
but the least nice program being able to run in some conditions.  The
algorithm which adjusts the priority now subtracts PRIO_MIN to do
things properly, and the ESTCPULIM() algorithm was updated to use
PRIO_TOTAL (PRIO_MAX - PRIO_MIN) to calculate the estcpu.

NICE_WEIGHT is now 1 to accomodate the full range of priorities better
(a -20 process with full CPU time has the priority of a +0 process with
no CPU time).  There are now 20 queues (exactly; 80 priorities) for
use in user processes' scheduling, and PUSER has been lowered to 48
to accomplish this.

This means, to the user, that things will be scheduled more correctly
(noticeable), there is no lock-up anymore WRT a niced -20 process
never releasing the CPU time for other processes.  In this fair system,
tsleep()ed < PUSER processes now will get the proper higher priority
than priority >= PUSER user processes.

The detective work of this was done by me, along with part of the
solution.  Luoqi Chen has provided most of the solution, and really
helped me understand what was happening better, to boot :)

Submitted by:   luoqi
Concept reviewed by:    bde
2000-04-30 18:33:43 +00:00
..
1999-10-29 18:09:36 +00:00
2000-04-02 09:26:51 +00:00
1999-10-29 18:09:36 +00:00
1999-08-28 01:08:13 +00:00
1999-08-28 01:08:13 +00:00
1999-11-14 13:54:44 +00:00
2000-04-22 15:13:06 +00:00
1999-10-05 21:19:41 +00:00
1999-08-28 01:08:13 +00:00
2000-04-29 16:25:22 +00:00
2000-04-29 16:25:22 +00:00
2000-04-26 00:20:01 +00:00
2000-04-29 11:32:15 +00:00
1999-11-21 19:03:20 +00:00
1999-08-28 01:08:13 +00:00
1999-08-28 01:08:13 +00:00
1999-08-28 01:08:13 +00:00
1999-08-28 01:08:13 +00:00
2000-04-29 16:25:22 +00:00
2000-03-20 16:28:35 +00:00
2000-03-20 16:28:35 +00:00