lkml.org 
[lkml]   [2009]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patchlet] Re: Epic regression in throughput since v2.6.23
From
Date
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.
>



\
 
 \ /
  Last update: 2009-09-17 07:09    [W:0.312 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site