[PATCH V2] sched/cpufreq: calculate util / cap in advance in map_util_freq()

[PATCH V2] sched/cpufreq: calculate util / cap in advance in map_util_freq()

[Chunyan Zhang]

From: Vincent Wang <vincent.wang@unisoc.com>

When a task that is in_iowait state is enqueued, cpufreq_update_util()
will be invoked with SCHED_CPUFREQ_IOWAIT flag. In this case,the value
of util and cap, which are parameters used in map_util_freq(), will be
cpu frequency, instead of cpu util and capactiy.

For some 32bit architectures, the size of unsigned long is 32. When
calculating freq, there may be an overflow error in this expression:

freq = (freq + (freq >> 2)) * util / cap;

This patch will fix this overflow risk by calulating util / cap in advance,
whether they be frequency or util.

Signed-off-by: Vincent Wang <vincent.wang@unisoc.com>
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
---
Changes from V1:
* Rebased onto v5.0-rc1;
* Addressed comments from Quentin Perret.
---
 include/linux/sched/cpufreq.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/sched/cpufreq.h b/include/linux/sched/cpufreq.h
index afa940c..3f93c32 100644
--- a/include/linux/sched/cpufreq.h
+++ b/include/linux/sched/cpufreq.h
@@ -24,7 +24,7 @@ void cpufreq_remove_update_util_hook(int cpu);
 static inline unsigned long map_util_freq(unsigned long util,
 					unsigned long freq, unsigned long cap)
 {
-	return (freq + (freq >> 2)) * util / cap;
+	return ((freq + (freq >> 2)) * ((util << 10) / cap)) >> 10;
 }
 #endif /* CONFIG_CPU_FREQ */
 
-- 
2.7.4

Re: [PATCH V2] sched/cpufreq: calculate util / cap in advance in map_util_freq()

[Peter Zijlstra]

On Thu, Jan 10, 2019 at 11:02:05AM +0800, Chunyan Zhang wrote:
> From: Vincent Wang <vincent.wang@unisoc.com>
> 
> When a task that is in_iowait state is enqueued, cpufreq_update_util()
> will be invoked with SCHED_CPUFREQ_IOWAIT flag. In this case,the value
> of util and cap, which are parameters used in map_util_freq(), will be
> cpu frequency, instead of cpu util and capactiy.
> 
> For some 32bit architectures, the size of unsigned long is 32. When
> calculating freq, there may be an overflow error in this expression:

Would it not be much better to fix that one case instead of adding extra
instructions for everyone all the time?