Messages in this thread | | | Date | Thu, 27 Sep 2012 21:24:27 +0200 | From | Borislav Petkov <> | Subject | Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected |
| |
On Thu, Sep 27, 2012 at 08:29:44PM +0200, Peter Zijlstra wrote: > > >> Or could we just improve the heuristics. What happens if the > > >> scheduling granularity is increased, for example? It's set to 1ms > > >> right now, with a logarithmic scaling by number of cpus. > > > > > > /proc/sys/kernel/sched_wakeup_granularity_ns=10000000 (10ms) > > > ------------------------------------------------------ > > > tps = 4994.730809 (including connections establishing) > > > tps = 5000.260764 (excluding connections establishing) > > > > > > A bit better over the default NO_WAKEUP_PREEMPTION setting. > > > > Ok, so this gives us something possible to actually play with. > > > > For example, maybe SCHED_TUNABLESCALING_LINEAR is more appropriate > > than SCHED_TUNABLESCALING_LOG. At least for WAKEUP_PREEMPTION. Hmm? > > Don't forget to run the desktop interactivity benchmarks after you're > done wriggling with this knob... wakeup preemption is important for most > those.
Setting sched_tunable_scaling to SCHED_TUNABLESCALING_LINEAR made wakeup_granularity go to 4ms:
sched_autogroup_enabled:1 sched_child_runs_first:0 sched_latency_ns:24000000 sched_migration_cost_ns:500000 sched_min_granularity_ns:3000000 sched_nr_migrate:32 sched_rt_period_us:1000000 sched_rt_runtime_us:950000 sched_shares_window_ns:10000000 sched_time_avg_ms:1000 sched_tunable_scaling:2 sched_wakeup_granularity_ns:4000000
pgbench results look good:
tps = 4997.675331 (including connections establishing) tps = 5003.256870 (excluding connections establishing)
This is still with Ingo's NO_WAKEUP_PREEMPTION patch.
Thanks.
-- Regards/Gruss, Boris.
| |