On Thu, 2012-09-27 at 21:24 +0200, Borislav Petkov wrote: > 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.
And wakeup preemption is still disabled as well, correct? -Mike -- 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/
