SCHED_ULE should not be the default

[George Mitchell]

On 12/14/11 21:05, Oliver Pinter wrote:
> [...]
> Hi!
>
> Can you try with this settings:
>
> op at opn ~>  sysctl kern.sched.
> kern.sched.cpusetsize: 8
> kern.sched.preemption: 0
> kern.sched.name: ULE
> kern.sched.slice: 13
> kern.sched.interact: 30
> kern.sched.preempt_thresh: 224
> kern.sched.static_boost: 152
> kern.sched.idlespins: 10000
> kern.sched.idlespinthresh: 16
> kern.sched.affinity: 1
> kern.sched.balance: 1
> kern.sched.balance_interval: 133
> kern.sched.steal_htt: 1
> kern.sched.steal_idle: 1
> kern.sched.steal_thresh: 1
> kern.sched.topology_spec:<groups>
>   <group level="1" cache-level="0">
>    <cpu count="2" mask="3">0, 1</cpu>
>    <children>
>     <group level="2" cache-level="2">
>      <cpu count="2" mask="3">0, 1</cpu>
>     </group>
>    </children>
>   </group>
> </groups>
> [...]

Sorry I didn't try this earlier, but I had time this morning.
Apparently you can't change kern.sched.preemption without
recompiling, so I did that.  It didn't help, and subjectively it
made interactive performance worse.  I changed preempt_thresh and
observed no difference.  There were only a couple of small
differences between your other settings and the 9.0-PRERELEASE
defaults.

Summing up for the record, in my original test:
1. It doesn't matter whether X is running or not.
2. The problem is not limited to two or fewer CPUs.  (It also happens
    for me on a six-CPU system.)
3. It doesn't require nCPU + 1 compute-bound processes, just nCPU.

With nCPU compute-bound processes running, with SCHED_ULE, any other
process that is interactive (which to me means frequently waiting for
I/O) gets ABYSMAL performance -- over an order of magnitude worse than
it gets with SCHED_4BSD under the same conditions.            -- George