[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d9ff7a8-5f05-6554-d019-9665536aea84@criteo.com>
Date: Wed, 20 Feb 2019 10:52:17 +0000
From: Erwan Velu <e.velu@...teo.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>,
Erwan Velu <erwanaliasr1@...il.com>
CC: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Viresh Kumar <viresh.kumar@...aro.org>,
"open list:CPU FREQUENCY SCALING FRAMEWORK"
<linux-pm@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cpufreq: Report if CPU doesn't report boost technologies
Le 20/02/2019 à 11:41, Rafael J. Wysocki a écrit :
> On Wed, Feb 20, 2019 at 11:11 AM Erwan Velu <erwanaliasr1@...il.com> wrote:
>> There is some rare cases where CPB (and possibly IDA) are missing on processors.
>> This is the case fixed by commit f7f3dc00f612 ("x86/cpu/AMD: Fix erratum 1076 (CPB bit)") and following.
>>
>> In such context, the boost status isn't reported by /sys/devices/system/cpu/cpufreq/boost.
> So I'm not really sure why the extra message is needed. It looks like
> this message will always be printed (with debug output enabled) if the
> current cpufreq driver is acpi-cpufreq and the boost attribute is not
> present in sysfs, which only is the case if CPB/IDA aren't there.
>
> Does it provide any additional information, then?
When you know and read the code, yes this patch is too obvious.
As a user when I was troubleshooting why the boost entry was _not_
populated on one CPU and was populated on another.
Running acpi-cpufreq with dyndbg, I would have found useful to get that
hint.
So that could helps users that never read that part of the code and
which are tricked into that configuration.
Erwan,
Powered by blists - more mailing lists