Date: Sat, 17 Dec 2011 12:33:21 -0500 From: George Mitchell <george+freebsd@m5p.com> To: Oliver Pinter <oliver.pntr@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: SCHED_ULE should not be the default Message-ID: <4EECD261.2080208@m5p.com> In-Reply-To: <CAPjTQNEJDE17TLH-mDrG_-_Qa9R5N3mSeXSYYWtqz_DFidzYQw@mail.gmail.com> References: <4EE1EAFE.3070408@m5p.com> <CAJ-FndDniGH8QoT=kUxOQ%2BzdVhWF0Z0NKLU0PGS-Gt=BK6noWw@mail.gmail.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <CAFHbX1%2B5PttyZuNnYot8emTn_AWkABdJCvnpo5rcRxVXj0ypJA@mail.gmail.com> <4EE933C6.4020209@zedat.fu-berlin.de> <CAPjTQNEJDE17TLH-mDrG_-_Qa9R5N3mSeXSYYWtqz_DFidzYQw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EECD261.2080208>