[lkml]   [2012]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: sched: Avoid SMT siblings in select_idle_sibling() if possible
* Peter Zijlstra <> [2012-03-26 10:36:00]:

> > tip tip + patch
> >
> > volano 1 1.29 (29% improvement)
> > sysbench [n3] 1 2 (100% improvement)
> > tbench 1 [n4] 1 1.07 (7% improvement)
> > tbench 8 [n5] 1 1.26 (26% improvement)
> > httperf [n6] 1 1.05 (5% improvement)
> > Trade 1 1.31 (31% improvement)
> That smells like there's more to the story, a 100% improvement is too
> much..

Yeah I have rubbed my eyes several times to make sure its true and ran
the same benchmark (sysbench) again now! I can recreate that ~100%
improvement with the patch even now.

To quickly re-cap my environment, I have a 16-cpu machine w/ 5 cgroups.
1 cgroup (8192 shares) hosts sysbench inside 8-vcpu VM while remaining 4
cgroups (1024 shares each) hosts 4 cpu hogs running on bare metal.
Given this overcommittment, select_idle_sibling() should mostly be a
no-op (i.e it won't find any idle cores and thus defaults to prev_cpu).
Also the only tasks that will (sleep and) wakeup are the VM tasks.

Since the patch potentially affects (improves) scheduling latencies, I measured
Sum(se.statistics.wait_sum) for the VM tasks over the benchmark run (5
iterations of sysbench).

tip : 987240 ms
tip + patch : 280275 ms

I will get more comprehensive perf data shortly and post.

From what I can tell, the huge improvement in benchmark score is coming from
reduced latencies for its VM tasks.

The hard part to figure out (when we are inside select_task_rq_fair()) is
whether any potential improvement in latencies (because of waking up on a
less loaded cpu) will offshoot the cost of potentially more L2-cache misses,
for which IMHO we don't have enough data to make a good decision.

- vatsa

 \ /
  Last update: 2012-03-26 19:37    [W:0.086 / U:0.380 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site