On 12/14/11 21:05, Oliver Pinter wrote:
[...] Hi!Can you try with this settings: op@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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
