Messages in this thread | | | From | "Doug Smythies" <> | Subject | RE: Performance of low-cpu utilisation benchmark regressed severely since 4.6 | Date | Mon, 24 Apr 2017 07:24:31 -0700 |
| |
On 2017.04.23 18:23 Srinivas Pandruvada wrote: > On Mon, 2017-04-24 at 02:59 +0200, Rafael J. Wysocki wrote: >> On Sun, Apr 23, 2017 at 5:31 PM, Doug Smythies <dsmythies@telus.net> wrote:
>>> It looks like the cost is mostly related to moving the load from >>> one CPU to >>> another and waiting for the new one to ramp up then. > Last time when we analyzed Mel's result last year this was the > conclusion. The problem was more apparent on systems with per core P- > state.
?? I have never seen this particular use case before. Unless I have looked the wrong thing, Mel's issue last year was a different use case.
...[cut]... >>>> We can do one more trick I forgot about. Namely, if we are about >>>> to increase >>>> the P-state, we can jump to the average between the target and >>>> the max >>>> instead of just the target, like in the appended patch (on top of >>>> linux-next). >>>> >>>> That will make the P-state selection really aggressive, so costly >>>> energetically, >>>> but it shoud small jumps of the average load above 0 to case big >>>> jumps of >>>> the target P-state. >>> I'm already seeing the energy costs of some of this stuff. >>> 3050.2 Seconds. >> Is this with or without reducing the sampling interval?
It was without reducing the sample interval.
So, it was the branch you referred us to the other day:
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
with your patch (now deleted from this thread) applied.
...[cut]...
>> Anyway, your results are somewhat counter-intuitive.
>> Would it be possible to run this workload with the linux-next branch >> and the schedutil governor and see if the patch at >> https://patchwork.kernel.org/patch/9671829/ makes any difference?
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next Plus that patch is in progress.
... Doug
| |