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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
