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>