Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1222996
| From | Morten Rasmussen <morten.rasmussen@arm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig |
| Date | 2015-09-11 19:20 +0200 |
| Message-ID | <q7A9s-89P-3@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <q6qFd-4GE-21@gated-at.bofh.it> <q6s4j-6PU-29@gated-at.bofh.it> <q6ufN-1tS-23@gated-at.bofh.it> <q6KaS-7Lb-13@gated-at.bofh.it> <q6Lqh-1gs-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, Sep 09, 2015 at 12:13:10PM +0100, Morten Rasmussen wrote: > On Wed, Sep 09, 2015 at 11:43:05AM +0200, Peter Zijlstra wrote: > > Sadly that makes the code worse; I get 14 mul instructions where > > previously I had 11. > > > > What happens is that GCC gets confused and cannot constant propagate the > > new variables, so what used to be shifts now end up being actual > > multiplications. > > > > With this, I get back to 11. Can you see what happens on ARM where you > > have both functions defined to non constants? > > We repeated the experiment on arm and arm64 but still with functions > defined to constant to compare with your results. The mul instruction > count seems to be somewhat compiler version dependent, but consistently > show no effect of the patch: > > arm before after > gcc4.9 12 12 > gcc4.8 10 10 > > arm64 before after > gcc4.9 11 11 > > I will get numbers with the arch-functions implemented as well and do > hackbench runs to see what happens in terms of performance. I have done some runs with the proposed fixes added: 1. PeterZ's util_sum shift fix (change util_sum). 2. Morten's scaling of weight instead of time (reduce bit loss). 3. PeterZ's unconditional calls to arch*() functions (compiler opt). To be clear: 2 includes 1, and 3 includes 1 and 2. Runs where done with the default (#define) implementation of the arch-functions and with arch specific implementation for ARM. I realized that just looking for 'mul' instructions in update_blocked_averages() is probably not a fair comparison on ARM as it turned out that it has quite a few multiply-accumulate instructions. So I have included the total count including those too. Test platforms: ARM TC2 (A7x3 only) perf stat --null --repeat 10 -- perf bench sched messaging -g 50 -l 200 #mul: grep -e mul (in update_blocked_averages()) #mul_all: grep -e mul -e mla -e mls -e mia (in update_blocked_averages()) gcc: 4.9.3 Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz perf stat --null --repeat 10 -- perf bench sched messaging -g 50 -l 15000 #mul: grep -e mul (in update_blocked_averages()) gcc: 4.9.2 Results: perf numbers are average of three (x10) runs. Raw data is available further down. ARM TC2 #mul #mul_all perf bench arch*() default arm default arm default arm 1 shift_fix 10 16 22 36 13.401 13.288 2 scaled_weight 12 14 30 32 13.282 13.238 3 unconditional 12 14 26 32 13.296 13.427 Intel E5-2690 #mul #mul_all perf bench arch*() default default default 1 shift_fix 13 14.786 2 scaled_weight 18 15.078 3 unconditional 14 15.195 Overall it appears that fewer 'mul' instructions doesn't necessarily mean better perf bench score. For ARM, 2 seems the best choice overall. While 1 is better for Intel. If we want to try avoid the bit loss by scaling weight instead of time, 2 is best for both. However, all that said, looking at the raw numbers there is a significant difference between runs of perf --repeat, so we can't really draw any strong conclusions. It all appears to be in the noise. I suggest that I spin a v2 of this series and go with scaled_weight to reduce bit loss. Any objections? While at it, should I include Yuyang's patch redefining the SCALE/SHIFT mess? Raw numbers: ARM TC2 shift_fix default_arch gcc4.9.3 #mul 10 #mul+mla+mls+mia 22 13.384416727 seconds time elapsed ( +- 0.17% ) 13.431014702 seconds time elapsed ( +- 0.18% ) 13.387434890 seconds time elapsed ( +- 0.15% ) shift_fix arm_arch gcc4.9.3 #mul 16 #mul+mla+mls+mia 36 13.271044081 seconds time elapsed ( +- 0.11% ) 13.310189123 seconds time elapsed ( +- 0.19% ) 13.283594740 seconds time elapsed ( +- 0.12% ) scaled_weight default_arch gcc4.9.3 #mul 12 #mul+mla+mls+mia 30 13.295649553 seconds time elapsed ( +- 0.20% ) 13.271634654 seconds time elapsed ( +- 0.19% ) 13.280081329 seconds time elapsed ( +- 0.14% ) scaled_weight arm_arch gcc4.9.3 #mul 14 #mul+mla+mls+mia 32 13.230659223 seconds time elapsed ( +- 0.15% ) 13.222276527 seconds time elapsed ( +- 0.15% ) 13.260275081 seconds time elapsed ( +- 0.21% ) unconditional default_arch gcc4.9.3 #mul 12 #mul+mla+mls+mia 26 13.274904460 seconds time elapsed ( +- 0.13% ) 13.307853511 seconds time elapsed ( +- 0.15% ) 13.304084844 seconds time elapsed ( +- 0.22% ) unconditional arm_arch gcc4.9.3 #mul 14 #mul+mla+mls+mia 32 13.432878577 seconds time elapsed ( +- 0.13% ) 13.417950552 seconds time elapsed ( +- 0.12% ) 13.431682719 seconds time elapsed ( +- 0.18% ) Intel shift_fix default_arch gcc4.9.2 #mul 13 14.905815416 seconds time elapsed ( +- 0.61% ) 14.811113694 seconds time elapsed ( +- 0.84% ) 14.639739309 seconds time elapsed ( +- 0.76% ) scaled_weight default_arch gcc4.9.2 #mul 18 15.113275474 seconds time elapsed ( +- 0.64% ) 15.056777680 seconds time elapsed ( +- 0.44% ) 15.064074416 seconds time elapsed ( +- 0.71% ) unconditional default_arch gcc4.9.2 #mul 14 15.105152500 seconds time elapsed ( +- 0.71% ) 15.346405473 seconds time elapsed ( +- 0.81% ) 15.132933523 seconds time elapsed ( +- 0.82% ) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Dietmar Eggemann <dietmar.eggemann@arm.com> - 2015-09-07 17:40 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Vincent Guittot <vincent.guittot@linaro.org> - 2015-09-07 18:30 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Dietmar Eggemann <dietmar.eggemann@arm.com> - 2015-09-07 21:00 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-07 21:50 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Dietmar Eggemann <dietmar.eggemann@arm.com> - 2015-09-08 14:50 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Vincent Guittot <vincent.guittot@linaro.org> - 2015-09-08 09:30 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-08 14:30 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-08 15:00 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Vincent Guittot <vincent.guittot@linaro.org> - 2015-09-08 16:10 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Morten Rasmussen <morten.rasmussen@arm.com> - 2015-09-08 16:40 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Vincent Guittot <vincent.guittot@linaro.org> - 2015-09-08 16:50 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Morten Rasmussen <morten.rasmussen@arm.com> - 2015-09-08 16:30 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-08 17:40 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig bsegall@google.com - 2015-09-10 00:30 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Morten Rasmussen <morten.rasmussen@arm.com> - 2015-09-10 13:10 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Vincent Guittot <vincent.guittot@linaro.org> - 2015-09-10 13:20 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Morten Rasmussen <morten.rasmussen@arm.com> - 2015-09-10 14:10 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Yuyang Du <yuyang.du@intel.com> - 2015-09-11 10:40 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig bsegall@google.com - 2015-09-10 19:30 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Morten Rasmussen <morten.rasmussen@arm.com> - 2015-09-08 18:50 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-09 11:50 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-09 11:50 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Morten Rasmussen <morten.rasmussen@arm.com> - 2015-09-09 13:10 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Morten Rasmussen <morten.rasmussen@arm.com> - 2015-09-11 19:20 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-17 12:00 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-17 12:50 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Yuyang Du <yuyang.du@intel.com> - 2015-09-21 11:10 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig bsegall@google.com - 2015-09-21 19:40 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Yuyang Du <yuyang.du@intel.com> - 2015-09-22 09:30 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Leo Yan <leo.yan@linaro.org> - 2015-09-11 09:50 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Morten Rasmussen <morten.rasmussen@arm.com> - 2015-09-11 12:00 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Leo Yan <leo.yan@linaro.org> - 2015-09-11 16:20 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Yuyang Du <yuyang.du@intel.com> - 2015-09-10 05:00 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-10 12:10 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Vincent Guittot <vincent.guittot@linaro.org> - 2015-09-08 15:50 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-08 16:20 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Vincent Guittot <vincent.guittot@linaro.org> - 2015-09-08 17:20 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Dietmar Eggemann <dietmar.eggemann@arm.com> - 2015-09-08 15:00 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Vincent Guittot <vincent.guittot@linaro.org> - 2015-09-08 16:10 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Dietmar Eggemann <dietmar.eggemann@arm.com> - 2015-09-08 16:30 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Yuyang Du <yuyang.du@intel.com> - 2015-09-10 06:10 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-10 12:10 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Yuyang Du <yuyang.du@intel.com> - 2015-09-11 10:20 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Morten Rasmussen <morten.rasmussen@arm.com> - 2015-09-11 12:30 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig bsegall@google.com - 2015-09-11 19:10 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Yuyang Du <yuyang.du@intel.com> - 2015-09-12 04:20 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig bsegall@google.com - 2015-09-14 19:40 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Morten Rasmussen <morten.rasmussen@arm.com> - 2015-09-14 15:00 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig bsegall@google.com - 2015-09-14 19:40 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Yuyang Du <yuyang.du@intel.com> - 2015-09-15 08:50 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig bsegall@google.com - 2015-09-15 19:20 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Yuyang Du <yuyang.du@intel.com> - 2015-09-16 04:30 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig bsegall@google.com - 2015-09-16 19:10 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Yuyang Du <yuyang.du@intel.com> - 2015-09-17 12:30 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Morten Rasmussen <morten.rasmussen@arm.com> - 2015-09-15 10:40 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-16 17:50 +0200
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig Peter Zijlstra <peterz@infradead.org> - 2015-09-08 13:50 +0200
[tip:sched/core] sched/fair: Get rid of scaling utilization by capacity_orig tip-bot for Dietmar Eggemann <tipbot@zytor.com> - 2015-09-13 13:10 +0200
csiph-web