Messages in this thread | | | Subject | Re: [patchlet] Re: Epic regression in throughput since v2.6.23 | From | Mike Galbraith <> | Date | Thu, 17 Sep 2009 07:06:40 +0200 |
| |
Aw poo, forgot to add Peter to CC list before poking xmit.
On Thu, 2009-09-17 at 06:55 +0200, Mike Galbraith wrote: > On Wed, 2009-09-16 at 23:18 +0000, Serge Belyshev wrote: > > Ingo Molnar <mingo@elte.hu> writes: > > > > > Ok, i think we've got a handle on that finally - mind checking latest > > > -tip? > > > > Kernel build benchmark: > > http://img11.imageshack.us/img11/4544/makej20090916.png > > > > I have also repeated video encode benchmarks described here: > > http://article.gmane.org/gmane.linux.kernel/889444 > > > > "x264 --preset ultrafast": > > http://img11.imageshack.us/img11/9020/ultrafast20090916.png > > > > "x264 --preset medium": > > http://img11.imageshack.us/img11/7729/medium20090916.png > > Pre-ramble.. > Most of the performance differences I've examined in all these CFS vs > BFS threads boil down to fair scheduler vs unfair scheduler. If you > favor hogs, naturally, hogs getting more bandwidth perform better than > hogs getting their fair share. That's wonderful for hogs, somewhat less > than wonderful for their competition. That fairness is not necessarily > the best thing for throughput is well known. If you've got a single > dissimilar task load running alone, favoring hogs may perform better.. > or not. What about mixed loads though? Is the throughput of frequent > switchers less important than hog throughput? > > Moving right along.. > > That x264 thing uncovered an interesting issue within CFS. That load is > a frequent clone() customer, and when it has to compete against a not so > fork/clone happy load, it suffers mightily. Even when running solo, ie > only competing against it's own siblings, IFF sleeper fairness is > enabled, the pain of thread startup latency is quite visible. With > concurrent loads, it is agonizingly painful. > > concurrent load test > tbench 8 vs > x264 --preset ultrafast --no-scenecut --sync-lookahead 0 --qp 20 -o /dev/null --threads 8 soccer_4cif.y4m > > (i can turn knobs and get whatever numbers i want, including > outperforming bfs, concurrent or solo.. not the point) > > START_DEBIT > encoded 600 frames, 44.29 fps, 22096.60 kb/s > encoded 600 frames, 43.59 fps, 22096.60 kb/s > encoded 600 frames, 43.78 fps, 22096.60 kb/s > encoded 600 frames, 43.77 fps, 22096.60 kb/s > encoded 600 frames, 45.67 fps, 22096.60 kb/s > > 8 1068214 672.35 MB/sec execute 57 sec > 8 1083785 672.16 MB/sec execute 58 sec > 8 1099188 672.18 MB/sec execute 59 sec > 8 1114626 672.00 MB/sec cleanup 60 sec > 8 1114626 671.96 MB/sec cleanup 60 sec > > NO_START_DEBIT > encoded 600 frames, 123.19 fps, 22096.60 kb/s > encoded 600 frames, 123.85 fps, 22096.60 kb/s > encoded 600 frames, 120.05 fps, 22096.60 kb/s > encoded 600 frames, 123.43 fps, 22096.60 kb/s > encoded 600 frames, 121.27 fps, 22096.60 kb/s > > 8 848135 533.79 MB/sec execute 57 sec > 8 860829 534.08 MB/sec execute 58 sec > 8 872840 533.74 MB/sec execute 59 sec > 8 885036 533.66 MB/sec cleanup 60 sec > 8 885036 533.64 MB/sec cleanup 60 sec > > 2.6.31-bfs221-smp > encoded 600 frames, 169.00 fps, 22096.60 kb/s > encoded 600 frames, 163.85 fps, 22096.60 kb/s > encoded 600 frames, 161.00 fps, 22096.60 kb/s > encoded 600 frames, 155.57 fps, 22096.60 kb/s > encoded 600 frames, 162.01 fps, 22096.60 kb/s > > 8 458328 287.67 MB/sec execute 57 sec > 8 464442 288.68 MB/sec execute 58 sec > 8 471129 288.71 MB/sec execute 59 sec > 8 477643 288.61 MB/sec cleanup 60 sec > 8 477643 288.60 MB/sec cleanup 60 sec > > patchlet: > > sched: disable START_DEBIT. > > START_DEBIT induces unfairness to loads which fork/clone frequently when they > must compete against loads which do not. > > > Signed-off-by: Mike Galbraith <efault@gmx.de> > Cc: Ingo Molnar <mingo@elte.hu> > Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> > LKML-Reference: <new-submission> > > kernel/sched_features.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/kernel/sched_features.h b/kernel/sched_features.h > index d5059fd..2fc94a0 100644 > --- a/kernel/sched_features.h > +++ b/kernel/sched_features.h > @@ -23,7 +23,7 @@ SCHED_FEAT(NORMALIZED_SLEEPER, 0) > * Place new tasks ahead so that they do not starve already running > * tasks > */ > -SCHED_FEAT(START_DEBIT, 1) > +SCHED_FEAT(START_DEBIT, 0) > > /* > * Should wakeups try to preempt running tasks. >
| |