[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH 04/31] cpufreq: make turbo settings to be configurable



Hi, Jan.

Sorry for the late response.

On Mon, May 7, 2018 at 6:39 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 09.11.17 at 18:09, <olekstysh@xxxxxxxxx> wrote:
>> --- a/xen/drivers/cpufreq/Kconfig
>> +++ b/xen/drivers/cpufreq/Kconfig
>> @@ -1,3 +1,6 @@
>>
>>  config HAS_CPUFREQ
>>       bool
>> +
>> +config HAS_CPU_TURBO
>> +     bool
>
> This is about cpufreq, so HAS_CPUFREQ_TURBO please.
>
> Also please try to limit the number of #ifdef-s, perhaps by way of introducing
> a few helpers (ending up empty without that setting enabled).

I would like to inform you that we decided to drop this patch. We can
go on without it. Thanks to Stefano
for the valuable comments.

All what we need at the moment regarding "turbo frequencies" is to
"correct the way of defining second_max_freq".
But it is going to be an another patch.

BTW, what do you think about the following:

Another question is second_max_freq. As I understand, it is highest
non-turbo frequency calculated by framework to limit target frequency
when turbo mode "is disabled". And Xen assumes that second_max_freq is
always P1 if turbo mode is on.
But, there might be a case when a few highest frequencies are
turbo-frequencies. So, I propose to add an extra flag for handling
that. So, each CPUFreq driver responsibility will be to mark
turbo-frequency(ies) for the framework to properly calculate
second_max_freq.

Something like that:

diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 25bf983..122a88b 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -226,7 +226,8 @@ int cpufreq_frequency_table_cpuinfo(struct
cpufreq_policy *policy,
 #ifdef CONFIG_HAS_CPU_TURBO
     for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
         unsigned int freq = table[i].frequency;
-        if (freq == CPUFREQ_ENTRY_INVALID || freq == max_freq)
+        if ((freq == CPUFREQ_ENTRY_INVALID) ||
+            (table[i].flags & CPUFREQ_BOOST_FREQ))
             continue;
         if (freq > second_max_freq)
             second_max_freq = freq;
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index 2e0c16a..77b29da 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -204,7 +204,11 @@ void cpufreq_verify_within_limits(struct
cpufreq_policy *policy,
 #define CPUFREQ_ENTRY_INVALID ~0
 #define CPUFREQ_TABLE_END     ~1

+/* Special Values of .flags field */
+#define CPUFREQ_BOOST_FREQ    (1 << 0)
+
 struct cpufreq_frequency_table {
+       unsigned int    flags;
     unsigned int    index;     /* any */
     unsigned int    frequency; /* kHz - doesn't need to be in ascending
                                 * order */

Both existing on x86 CPUFreq drivers just need to mark P0 frequency as
a turbo-frequency if turbo mode "is supported".

>
> Jan
>
>

-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.