Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1445383imu; Wed, 9 Jan 2019 19:06:28 -0800 (PST) X-Google-Smtp-Source: ALg8bN6nBErXHdy9DeX40CB+Nn4itK07UdnwUR3iDFNWbHRRs7EibcSc8StzhO14xWtalTqXI9Eo X-Received: by 2002:a17:902:4:: with SMTP id 4mr8674642pla.20.1547089588390; Wed, 09 Jan 2019 19:06:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547089588; cv=none; d=google.com; s=arc-20160816; b=b+54afrkAgQUC06MMcH7S42yyF0cBogCiiKihpePzeWUSSM2li38MaUHpmhaWW8S4m PX3Ai4n32Vk+zbCizkhN9iylW0P+h+CdaxwIaqhWQlKwouX9rPdHTRtly0Y3eo36qjZ5 CBIgD/kWmCbweaF/m610qosuKmfC7Z6Wr5Twoc11gamERVGQY4+g0MOm4EzAWogJ9DLA /2cvlvXhaWc88XSZsIC7HsdkS5x3Yrd53ewLxscGMFOXVEKlTcfSFReWpa8OQw5ImlWR 7Xxnpw3J5iouoTU4u9iF5q7D0IfXpT4qUvABWaJ80OL/Kwt4+5+PUdkQ0UpBBc7ZJbLP kz7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=taeseOCoWwYDv6afVYAyMwaRRaWyYteThS3cEbaDY0k=; b=yNfVr7LpdU9b2knVGNxR7Xd2EjMXWxw0d2VD0mEOL/X9LdwZTi4YTomY9PEepTfMDS OS2n6J90MRNoAJObK0g8qHXT8x7LbU5BLVPsw049LW6sKgx3f0gi+9HSDrxaMhcP4UTC x+WGIHrcyRmDVsn8XVxlDVapvWlfg6rwdpMJQmJ6oVDY1joBmVQB80iWaXFZjmIiDR47 M6CndswmD5FTSUu8qKGcrHK8gS9vG1p2uMJ9kc5pcg2qle0wy9I9ZElibdZL8ISaLOsZ 3e6+AHkGmdLtSTlGTAuydjNY6hO+IdGOIvz5jNNeasfeE8DlidFoFui0x0XVttAmIcCa 5aBQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k33si70621200pld.374.2019.01.09.19.06.13; Wed, 09 Jan 2019 19:06:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727160AbfAJDEm (ORCPT + 99 others); Wed, 9 Jan 2019 22:04:42 -0500 Received: from sci-ig2.spreadtrum.com ([222.66.158.135]:49599 "EHLO SHSQR01.spreadtrum.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1726541AbfAJDEm (ORCPT ); Wed, 9 Jan 2019 22:04:42 -0500 Received: from ig2.spreadtrum.com (bjmbx01.spreadtrum.com [10.0.64.7]) by SHSQR01.spreadtrum.com with ESMTPS id x0A31w5X043523 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2019 11:02:00 +0800 (CST) (envelope-from Chunyan.Zhang@unisoc.com) Received: from localhost (10.0.93.106) by BJMBX01.spreadtrum.com (10.0.64.7) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 10 Jan 2019 11:02:09 +0800 From: Chunyan Zhang To: Ingo Molnar , Peter Zijlstra CC: Vincent Wang , Quentin Perret , , Chunyan Zhang , Chunyan Zhang Subject: [PATCH V2] sched/cpufreq: calculate util / cap in advance in map_util_freq() Date: Thu, 10 Jan 2019 11:02:05 +0800 Message-ID: <1547089325-15691-1-git-send-email-chunyan.zhang@unisoc.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.0.93.106] X-ClientProxiedBy: SHCAS02.spreadtrum.com (10.0.1.202) To BJMBX01.spreadtrum.com (10.0.64.7) X-MAIL: SHSQR01.spreadtrum.com x0A31w5X043523 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vincent Wang 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 Signed-off-by: Chunyan Zhang --- 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