lkml.org 
[lkml]   [2018]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Commit 554c8aa8ecad causing severe performance degression with pcc-cpufreq
    On Tue, Jul 17, 2018 at 4:03 PM, Andreas Herrmann <aherrmann@suse.com> wrote:
    > On Tue, Jul 17, 2018 at 12:21:36PM +0200, Andreas Herrmann wrote:
    >> On Tue, Jul 17, 2018 at 12:09:21PM +0200, Rafael J. Wysocki wrote:
    >
    > ---8<---
    >
    >> > OK, the patch is below.
    >> >
    >> > First, I hope that if "Collaborative Power Control" is disabled, it will
    >> > simply hide the PCCH object and so intel_pstate will still not load then.
    >>
    >> PCCH is hidden in that case.
    >>
    >> > The main question basically is what the OS is expected to do if
    >> > "Dynamic Power Savings Mode" is set. If we are *expected* to use
    >> > the PCC interface then, intel_pstate may not work in that case, but
    >> > I suspect that the PCC interface allows extra energy to be saved
    >> > over what is possible without it.
    >>
    >> I'll test it and see what happens.
    >
    > I've tested it on top of v4.18-rc5-36-g30b06abfb92b. intel_pstate now
    > loads instead of pcc-cpufreq and system looks stable.
    >
    > When disabling "Collaborative Power Control" no cpufreq driver is loaded
    > (as expected).
    >
    > Performance (with kernbench) is as expected (always better than any
    > brew of pcc-cpufreq + misc modifications to this driver + partial
    > rollback of commit 554c8aa8ecad).
    >
    > If you like you can add either Tested-by or
    > Reviewed-by: Andreas Herrmann <aherrmann@suse.com>
    >
    > I think this patch should be tagged for 4.17-stable.

    OK, thank you for testing!

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