linux-kernel - RE: Performance of low-cpu utilisation benchmark regressed severely since 4.6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 24 Apr 2017 07:24:31 -0700
From:   "Doug Smythies" <dsmythies@...us.net>
To:     "'Srinivas Pandruvada'" <srinivas.pandruvada@...ux.intel.com>,
        "'Rafael J. Wysocki'" <rafael@...nel.org>
Cc:     "'Rafael J. Wysocki'" <rjw@...ysocki.net>,
        "'Mel Gorman'" <mgorman@...hsingularity.net>,
        "'Rafael Wysocki'" <rafael.j.wysocki@...el.com>,
        'Jörg Otte' <jrg.otte@...il.com>,
        "'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>,
        "'Linux PM'" <linux-pm@...r.kernel.org>,
        "Doug Smythies" <dsmythies@...us.net>
Subject: RE: Performance of low-cpu utilisation benchmark regressed severely since 4.6

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@...us.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