System load greater than logical cores and idprio 30 getting time.

[Dewayne Geraghty]

I don't understand why processes running at idpro 30 are gettting as
much CPU time as stated below when the load average is greater than the
number of logical cores.  I don't think its just a measuring error as I
have other short lived processes that also complete at idprio 31.  The
scheduler for this server is
kern.sched.name: ULE
kern.sched.interact: 0

This top extract was taken from a Xeon E3-1230L with 8 logical cores,
running 10.1Stable built/installed May 6,2015.

-- top extract --
last pid: 83135;  load averages: 11.32,  8.98, 
6.24                                          up 1+01:33:51  14:42:19
81 processes:  13 running, 68 sleeping
CPU: 95.9% user,  0.0% nice,  4.1% system,  0.0% interrupt,  0.0% idle
Mem: 299M Active, 5507M Inact, 1351M Wired, 5580K Cache, 899M Buf, 568M Free
Swap: 3881M Total, 16M Used, 3865M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU
COMMAND
40867 root          1 154  i30 50316K  4720K RUN     2  17:59  42.97%
ssh-keygen
40869 root          1 154  i30 50316K  4728K RUN     6  17:49  42.48%
ssh-keygen
83099 root          1  76    0 86468K 70696K RUN     4   0:02  16.46% c++

And couple of hours later (note not WCPU)

last pid: 21436;  load averages: 20.13, 14.73,
12.00                                          up 1+04:15:45  17:24:13
101 processes: 23 running, 78 sleeping
CPU: 95.6% user,  0.0% nice,  4.4% system,  0.0% interrupt,  0.0% idle
Mem: 724M Active, 5292M Inact, 1241M Wired, 32M Cache, 847M Buf, 443M Free
Swap: 3881M Total, 21M Used, 3861M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME     CPU
COMMAND
20141 root          1 155  i31 83084K 37688K RUN     7   0:09  25.98%
ssh-keygen
21380 root          1  79    0   110M   101M CPU3    3   0:03  24.46% c++
21340 root          1  78    0 74492K 66468K CPU4    4   0:03  20.46% c++

I recall the BSD scheduler behaving as expected, ie when the load >
cores, then idprio 31 processes barely received any time.

Regards, Dewayne.