Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1490331 > unrolled thread

[PATCH v2 0/2] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes

Started byAndreas Herrmann <aherrmann@suse.com>
First post2016-09-23 19:00 +0200
Last post2016-10-11 08:40 +0200
Articles 6 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v2 0/2] cpufreq: pcc-cpufreq: Re-introduce deadband effect to  reduce number of frequency changes Andreas Herrmann <aherrmann@suse.com> - 2016-09-23 19:00 +0200
    [PATCH v2 2/2] cpufreq/pcc-cpufreq: Make use of map_load_to_freq op Andreas Herrmann <aherrmann@suse.com> - 2016-09-23 19:10 +0200
      [PATCH v3 2/2] cpufreq/pcc-cpufreq: Make use of map_load_to_freq op Andreas Herrmann <aherrmann@suse.com> - 2016-09-26 11:10 +0200
    [PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize mapping  of load to frequency Andreas Herrmann <aherrmann@suse.com> - 2016-09-23 19:10 +0200
      Re: [PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize  mapping of load to frequency Viresh Kumar <viresh.kumar@linaro.org> - 2016-10-05 06:10 +0200
        Re: [PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize  mapping of load to frequency Andreas Herrmann <aherrmann@suse.com> - 2016-10-11 08:40 +0200

#1490331 — [PATCH v2 0/2] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes

FromAndreas Herrmann <aherrmann@suse.com>
Date2016-09-23 19:00 +0200
Subject[PATCH v2 0/2] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes
Message-ID<skBZo-6mq-7@gated-at.bofh.it>
Hi,

following patches address the performance degradation due to commit
6393d6a102 (cpufreq: ondemand: Eliminate the deadband effect) on
systems using pcc-cpufreq driver and ondemand governor.

Patch 1 introduces a generic_map_load_to_freq function which is
similar to what is used since commit 6393d6a102 (cpufreq: ondemand:
Eliminate the deadband effect) to calculate freq_next in od_update.

Patch 2 provides a specific function for pcc-cpufreq driver which
falls back to the calculation that was in the used before commit
6393d6a102.

I've also tested a pcc-specific function without deadband effect but
using only 10 frequency values. That was suboptimal in comparison to
patch 2. Here the performance data for this comparison (kernel
compilation with different number of jobs):

            pcc specific map_load_to_freq     pcc specific map_load_to_freq
              function (with deadband)        function (10 frequency steps)
 # of jobs  user    sys   elapsed   % CPU      user    sys   elapsed   % CPU
    2      413.19  102.34  250.97   205.00    426.21  106.32  260.00   204.00
    4      390.56  120.79  127.25   401.20    408.38  124.03  132.63   401.00
    8      354.22  140.09   64.20   769.60    383.33  146.31   68.70   770.40
   16      384.20  148.69   37.07  1436.60    466.20  164.18   43.30  1455.00
   32      496.70  152.77   25.15  2581.40    658.50  179.74   31.27  2680.60
   64      399.48   49.13   12.80  3505.80    404.27   51.24   13.14  3467.00
  120      406.52   46.89   13.60  3331.60    409.42   48.71   13.58  3371.40


Regards,

Andreas

[toc] | [next] | [standalone]

#1490336 — [PATCH v2 2/2] cpufreq/pcc-cpufreq: Make use of map_load_to_freq op

FromAndreas Herrmann <aherrmann@suse.com>
Date2016-09-23 19:10 +0200
Subject[PATCH v2 2/2] cpufreq/pcc-cpufreq: Make use of map_load_to_freq op
Message-ID<skC94-6EN-3@gated-at.bofh.it>
In reply to#1490331
Commit 6393d6a102 (cpufreq: ondemand: Eliminate the deadband effect)
introduced a performance regression for systems using pcc-cpufreq and
ondemand governor. This is measurable with different workloads. E.g.
wall-clock time for kernel compilation significantly increased.

The elimination of the deadband effect significantly increased the
number of frequency changes with pcc-cpufreq.

Provide a pcc-cpufreq specific function that reintroduces the mapping
of load to frequency which was used before commit 6393d6a102 and hence
re-introduces the deadband effect for this cpufreq driver.

Performance results (kernel compile with different number of jobs)
based on 4.8.0-rc7 (with and w/o my patches on top) from
an HP ProLiant DL580 Gen8 system using pcc-cpufreq:
 - Intel(R) Xeon(R) CPU E7-4890 v2 @ 2.80GHz
 - 60 CPUs, 128GB RAM
                                                       pcc specific
            generic_map_load_to_freq function     map_load_to_freq function
 # of jobs    user    sys   elapsed   % CPU      user    sys   elapsed   % CPU
    2        445.56  111.22  273.35   203.00    413.19  102.34  250.97   205.00
    4        445.61  126.10  143.12   399.00    390.56  120.79  127.25   401.20
    8        483.51  150.84   82.17   771.40    354.22  140.09   64.20   769.60
   16        628.01  185.54   55.02  1477.80    384.20  148.69   37.07  1436.60
   32        818.58  205.51   37.02  2765.40    496.70  152.77   25.15  2581.40
   64        406.22   51.84   13.84  3308.80    399.48   49.13   12.80  3505.80
  120        413.61   49.06   14.54  3181.00    406.52   46.89   13.60  3331.60

Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
Signed-off-by: Andreas Herrmann <aherrmann@suse.com>
---
 drivers/cpufreq/pcc-cpufreq.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index 3f0ce2a..1522747 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -39,6 +39,8 @@
 
 #include <acpi/processor.h>
 
+#include "cpufreq_governor.h"
+
 #define PCC_VERSION	"1.10.00"
 #define POLL_LOOPS 	300
 
@@ -534,6 +536,12 @@ out_free:
 	return ret;
 }
 
+static unsigned int pcc_map_load_to_freq(struct cpufreq_policy *policy,
+					unsigned int load)
+{
+	return (load * policy->cpuinfo.max_freq / 100);
+}
+
 static int pcc_cpufreq_cpu_init(struct cpufreq_policy *policy)
 {
 	unsigned int cpu = policy->cpu;
@@ -555,6 +563,8 @@ static int pcc_cpufreq_cpu_init(struct cpufreq_policy *policy)
 	policy->min = policy->cpuinfo.min_freq =
 		ioread32(&pcch_hdr->minimum_frequency) * 1000;
 
+	od_register_map_load_to_freq_handler(pcc_map_load_to_freq);
+
 	pr_debug("init: policy->max is %d, policy->min is %d\n",
 		policy->max, policy->min);
 out:
@@ -563,6 +573,7 @@ out:
 
 static int pcc_cpufreq_cpu_exit(struct cpufreq_policy *policy)
 {
+	od_unregister_map_load_to_freq_handler();
 	return 0;
 }
 
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1491165 — [PATCH v3 2/2] cpufreq/pcc-cpufreq: Make use of map_load_to_freq op

FromAndreas Herrmann <aherrmann@suse.com>
Date2016-09-26 11:10 +0200
Subject[PATCH v3 2/2] cpufreq/pcc-cpufreq: Make use of map_load_to_freq op
Message-ID<slA5b-1Xk-5@gated-at.bofh.it>
In reply to#1490336
Commit 6393d6a102 (cpufreq: ondemand: Eliminate the deadband effect)
introduced a performance regression for systems using pcc-cpufreq and
ondemand governor. This is measurable with different workloads. E.g.
wall-clock time for kernel compilation significantly increased.

The elimination of the deadband effect significantly increased the
number of frequency changes with pcc-cpufreq.

Provide a pcc-cpufreq specific function that reintroduces the mapping
of load to frequency which was used before commit 6393d6a102 and hence
re-introduces the deadband effect for this cpufreq driver.

Performance results (kernel compile with different number of jobs)
based on 4.8.0-rc7 (with and w/o my patches on top) from
an HP ProLiant DL580 Gen8 system using pcc-cpufreq:
 - Intel(R) Xeon(R) CPU E7-4890 v2 @ 2.80GHz
 - 60 CPUs, 128GB RAM
                                                       pcc specific
            generic_map_load_to_freq function     map_load_to_freq function
 # of jobs    user    sys   elapsed   % CPU      user    sys   elapsed   % CPU
    2        445.56  111.22  273.35   203.00    413.19  102.34  250.97   205.00
    4        445.61  126.10  143.12   399.00    390.56  120.79  127.25   401.20
    8        483.51  150.84   82.17   771.40    354.22  140.09   64.20   769.60
   16        628.01  185.54   55.02  1477.80    384.20  148.69   37.07  1436.60
   32        818.58  205.51   37.02  2765.40    496.70  152.77   25.15  2581.40
   64        406.22   51.84   13.84  3308.80    399.48   49.13   12.80  3505.80
  120        413.61   49.06   14.54  3181.00    406.52   46.89   13.60  3331.60

Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
Signed-off-by: Andreas Herrmann <aherrmann@suse.com>
---
 drivers/cpufreq/Kconfig.x86   |  2 +-
 drivers/cpufreq/pcc-cpufreq.c | 11 +++++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)

Kbuild test robot detected a build issue with my patch:

   drivers/built-in.o: In function `pcc_cpufreq_cpu_exit':
>> pcc-cpufreq.c:(.text+0x321019): undefined reference to `od_unregister_map_load_to_freq_handler'
   drivers/built-in.o: In function `pcc_cpufreq_cpu_init':
>> pcc-cpufreq.c:(.text+0x32136a): undefined reference to `od_register_map_load_to_freq_handler'

for configs that selected X86_PCC_CPUFREQ but not
CPU_FREQ_GOV_ONDEMAND.

This new patch version adds the required build dependency as my change
makes pcc-cpufreq dependent on cpufreq_ondemand.
Sorry for the omission in the previous patch version.


Regards,

Andreas

diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
index adbd1de..f159726 100644
--- a/drivers/cpufreq/Kconfig.x86
+++ b/drivers/cpufreq/Kconfig.x86
@@ -18,7 +18,7 @@ config X86_INTEL_PSTATE
 
 config X86_PCC_CPUFREQ
 	tristate "Processor Clocking Control interface driver"
-	depends on ACPI && ACPI_PROCESSOR
+	depends on CPU_FREQ_GOV_ONDEMAND && ACPI && ACPI_PROCESSOR
 	help
 	  This driver adds support for the PCC interface.
 
diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index 3f0ce2a..1522747 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -39,6 +39,8 @@
 
 #include <acpi/processor.h>
 
+#include "cpufreq_governor.h"
+
 #define PCC_VERSION	"1.10.00"
 #define POLL_LOOPS 	300
 
@@ -534,6 +536,12 @@ out_free:
 	return ret;
 }
 
+static unsigned int pcc_map_load_to_freq(struct cpufreq_policy *policy,
+					unsigned int load)
+{
+	return (load * policy->cpuinfo.max_freq / 100);
+}
+
 static int pcc_cpufreq_cpu_init(struct cpufreq_policy *policy)
 {
 	unsigned int cpu = policy->cpu;
@@ -555,6 +563,8 @@ static int pcc_cpufreq_cpu_init(struct cpufreq_policy *policy)
 	policy->min = policy->cpuinfo.min_freq =
 		ioread32(&pcch_hdr->minimum_frequency) * 1000;
 
+	od_register_map_load_to_freq_handler(pcc_map_load_to_freq);
+
 	pr_debug("init: policy->max is %d, policy->min is %d\n",
 		policy->max, policy->min);
 out:
@@ -563,6 +573,7 @@ out:
 
 static int pcc_cpufreq_cpu_exit(struct cpufreq_policy *policy)
 {
+	od_unregister_map_load_to_freq_handler();
 	return 0;
 }
 
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1490338 — [PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize mapping of load to frequency

FromAndreas Herrmann <aherrmann@suse.com>
Date2016-09-23 19:10 +0200
Subject[PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize mapping of load to frequency
Message-ID<skC94-6EN-11@gated-at.bofh.it>
In reply to#1490331
Introduce op for ondemand governor that is used to map load to
frequency. It allows a cpufreq driver to provide a specific mapping
function if the generic function is not optimal for the driver.

Performance results (kernel compile with different number of jobs)
based on 4.8.0-rc7 (with and w/o my patches on top) from
an HP ProLiant DL580 Gen8 system using pcc-cpufreq:
 - Intel(R) Xeon(R) CPU E7-4890 v2 @ 2.80GHz
 - 60 CPUs, 128GB RAM
 
                    vanilla                  generic_map_load_to_freq function
 # of jobs  user    sys   elapsed   % CPU      user    sys   elapsed   % CPU
    2      445.44  110.51  272.99   203.00    445.56  111.22  273.35   203.00
    4      444.41  126.20  142.81   399.00    445.61  126.10  143.12   399.00
    8      483.04  150.58   82.19   770.40    483.51  150.84   82.17   771.40
   16      626.81  185.01   55.00  1475.40    628.01  185.54   55.02  1477.80
   32      816.72  204.39   37.26  2740.00    818.58  205.51   37.02  2765.40
   64      406.59   51.12   14.04  3257.80    406.22   51.84   13.84  3308.80
  120      413.00   48.39   14.36  3211.20    413.61   49.06   14.54  3181.00

Similar tests on another system using acpi_cpufreq didn't show
significant performance differences between these two kernel versions.

Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
Signed-off-by: Andreas Herrmann <aherrmann@suse.com>
---
 drivers/cpufreq/cpufreq_governor.h |  5 +++++
 drivers/cpufreq/cpufreq_ondemand.c | 35 ++++++++++++++++++++++++++++++-----
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index ef1037e..9fef947 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -171,6 +171,8 @@ void cpufreq_dbs_governor_limits(struct cpufreq_policy *policy);
 struct od_ops {
 	unsigned int (*powersave_bias_target)(struct cpufreq_policy *policy,
 			unsigned int freq_next, unsigned int relation);
+	unsigned int (*map_load_to_freq)(struct cpufreq_policy *policy,
+			unsigned int load);
 };
 
 unsigned int dbs_update(struct cpufreq_policy *policy);
@@ -178,6 +180,9 @@ void od_register_powersave_bias_handler(unsigned int (*f)
 		(struct cpufreq_policy *, unsigned int, unsigned int),
 		unsigned int powersave_bias);
 void od_unregister_powersave_bias_handler(void);
+void od_register_map_load_to_freq_handler(unsigned int (*f)
+		(struct cpufreq_policy *, unsigned int));
+void od_unregister_map_load_to_freq_handler(void);
 ssize_t store_sampling_rate(struct gov_attr_set *attr_set, const char *buf,
 			    size_t count);
 void gov_update_cpu_data(struct dbs_data *dbs_data);
diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index 3a1f49f..d245f1c 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -112,6 +112,20 @@ static void ondemand_powersave_bias_init(struct cpufreq_policy *policy)
 	dbs_info->freq_lo = 0;
 }
 
+/*
+ * Calculate the next frequency proportional to load
+ */
+static unsigned int generic_map_load_to_freq(struct cpufreq_policy *policy,
+					unsigned int load)
+{
+	unsigned int min_f, max_f;
+
+	min_f = policy->cpuinfo.min_freq;
+	max_f = policy->cpuinfo.max_freq;
+
+	return (min_f + load * (max_f - min_f) / 100);
+}
+
 static void dbs_freq_increase(struct cpufreq_policy *policy, unsigned int freq)
 {
 	struct policy_dbs_info *policy_dbs = policy->governor_data;
@@ -150,12 +164,9 @@ static void od_update(struct cpufreq_policy *policy)
 			policy_dbs->rate_mult = dbs_data->sampling_down_factor;
 		dbs_freq_increase(policy, policy->max);
 	} else {
-		/* Calculate the next frequency proportional to load */
-		unsigned int freq_next, min_f, max_f;
+		unsigned int freq_next;
 
-		min_f = policy->cpuinfo.min_freq;
-		max_f = policy->cpuinfo.max_freq;
-		freq_next = min_f + load * (max_f - min_f) / 100;
+		freq_next = od_ops.map_load_to_freq(policy, load);
 
 		/* No longer fully busy, reset rate_mult */
 		policy_dbs->rate_mult = 1;
@@ -410,6 +421,7 @@ static void od_start(struct cpufreq_policy *policy)
 
 static struct od_ops od_ops = {
 	.powersave_bias_target = generic_powersave_bias_target,
+	.map_load_to_freq = generic_map_load_to_freq,
 };
 
 static struct dbs_governor od_dbs_gov = {
@@ -476,6 +488,19 @@ void od_unregister_powersave_bias_handler(void)
 }
 EXPORT_SYMBOL_GPL(od_unregister_powersave_bias_handler);
 
+void od_register_map_load_to_freq_handler(unsigned int (*f)
+					(struct cpufreq_policy *, unsigned int))
+{
+	od_ops.map_load_to_freq = f;
+}
+EXPORT_SYMBOL_GPL(od_register_map_load_to_freq_handler);
+
+void od_unregister_map_load_to_freq_handler(void)
+{
+	od_ops.map_load_to_freq = generic_map_load_to_freq;
+}
+EXPORT_SYMBOL_GPL(od_unregister_map_load_to_freq_handler);
+
 static int __init cpufreq_gov_dbs_init(void)
 {
 	return cpufreq_register_governor(CPU_FREQ_GOV_ONDEMAND);
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1495689 — Re: [PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize mapping of load to frequency

FromViresh Kumar <viresh.kumar@linaro.org>
Date2016-10-05 06:10 +0200
SubjectRe: [PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize mapping of load to frequency
Message-ID<soLGN-3XX-9@gated-at.bofh.it>
In reply to#1490338
On 23-09-16, 19:02, Andreas Herrmann wrote:
> Introduce op for ondemand governor that is used to map load to
> frequency. It allows a cpufreq driver to provide a specific mapping
> function if the generic function is not optimal for the driver.
> 
> Performance results (kernel compile with different number of jobs)
> based on 4.8.0-rc7 (with and w/o my patches on top) from
> an HP ProLiant DL580 Gen8 system using pcc-cpufreq:
>  - Intel(R) Xeon(R) CPU E7-4890 v2 @ 2.80GHz
>  - 60 CPUs, 128GB RAM
>  
>                     vanilla                  generic_map_load_to_freq function
>  # of jobs  user    sys   elapsed   % CPU      user    sys   elapsed   % CPU
>     2      445.44  110.51  272.99   203.00    445.56  111.22  273.35   203.00
>     4      444.41  126.20  142.81   399.00    445.61  126.10  143.12   399.00
>     8      483.04  150.58   82.19   770.40    483.51  150.84   82.17   771.40
>    16      626.81  185.01   55.00  1475.40    628.01  185.54   55.02  1477.80
>    32      816.72  204.39   37.26  2740.00    818.58  205.51   37.02  2765.40
>    64      406.59   51.12   14.04  3257.80    406.22   51.84   13.84  3308.80
>   120      413.00   48.39   14.36  3211.20    413.61   49.06   14.54  3181.00
> 
> Similar tests on another system using acpi_cpufreq didn't show
> significant performance differences between these two kernel versions.
> 
> Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
> Signed-off-by: Andreas Herrmann <aherrmann@suse.com>
> ---
>  drivers/cpufreq/cpufreq_governor.h |  5 +++++
>  drivers/cpufreq/cpufreq_ondemand.c | 35 ++++++++++++++++++++++++++++++-----
>  2 files changed, 35 insertions(+), 5 deletions(-)

NAK.

If we are absolutely required to hack it in some way, then I would
prefer your first patchset as the noise was limited to only your
driver.

We aren't going to provide such operations from the governors, sorry.

-- 
viresh

[toc] | [prev] | [next] | [standalone]

#1498626 — Re: [PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize mapping of load to frequency

FromAndreas Herrmann <aherrmann@suse.com>
Date2016-10-11 08:40 +0200
SubjectRe: [PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize mapping of load to frequency
Message-ID<sqYTf-3cr-5@gated-at.bofh.it>
In reply to#1495689
On Wed, Oct 05, 2016 at 09:31:18AM +0530, Viresh Kumar wrote:
> On 23-09-16, 19:02, Andreas Herrmann wrote:
> > Introduce op for ondemand governor that is used to map load to
> > frequency. It allows a cpufreq driver to provide a specific mapping
> > function if the generic function is not optimal for the driver.
> > 
> > Performance results (kernel compile with different number of jobs)
> > based on 4.8.0-rc7 (with and w/o my patches on top) from
> > an HP ProLiant DL580 Gen8 system using pcc-cpufreq:
> >  - Intel(R) Xeon(R) CPU E7-4890 v2 @ 2.80GHz
> >  - 60 CPUs, 128GB RAM
> >  
> >                     vanilla                  generic_map_load_to_freq function
> >  # of jobs  user    sys   elapsed   % CPU      user    sys   elapsed   % CPU
> >     2      445.44  110.51  272.99   203.00    445.56  111.22  273.35   203.00
> >     4      444.41  126.20  142.81   399.00    445.61  126.10  143.12   399.00
> >     8      483.04  150.58   82.19   770.40    483.51  150.84   82.17   771.40
> >    16      626.81  185.01   55.00  1475.40    628.01  185.54   55.02  1477.80
> >    32      816.72  204.39   37.26  2740.00    818.58  205.51   37.02  2765.40
> >    64      406.59   51.12   14.04  3257.80    406.22   51.84   13.84  3308.80
> >   120      413.00   48.39   14.36  3211.20    413.61   49.06   14.54  3181.00
> > 
> > Similar tests on another system using acpi_cpufreq didn't show
> > significant performance differences between these two kernel versions.
> > 
> > Link: https://marc.info/?i=20160819121814.GA17296%40suselix.suse.de
> > Signed-off-by: Andreas Herrmann <aherrmann@suse.com>
> > ---
> >  drivers/cpufreq/cpufreq_governor.h |  5 +++++
> >  drivers/cpufreq/cpufreq_ondemand.c | 35 ++++++++++++++++++++++++++++++-----
> >  2 files changed, 35 insertions(+), 5 deletions(-)
> 
> NAK.
> 
> If we are absolutely required to hack it in some way, then I would
> prefer your first patchset as the noise was limited to only your
> driver.
> 
> We aren't going to provide such operations from the governors, sorry.

Yep, understandable.


Andreas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web