Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp971355imu; Fri, 4 Jan 2019 10:27:30 -0800 (PST) X-Google-Smtp-Source: ALg8bN6lTO3FqgdIPV1BEgiA+tIP11cfqplufiatALvexE28E57ELIzLkPglWuXZ4IqxA8eeoeXq X-Received: by 2002:a17:902:9b87:: with SMTP id y7mr35485636plp.336.1546626450214; Fri, 04 Jan 2019 10:27:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546626450; cv=none; d=google.com; s=arc-20160816; b=YZ/cvnowTWsKDjCRq4jyJ7QMTrVJpoNud4vMOPaM4PKpIgSOTuVhMyqI/3I8F8YUTF VAv7U6i4WprQB8B0KkgLx/eMeOfqeBcSj31NeS8vV5SSHnomBN+3vpLaWrsGvvkAz/FT Sva/GW2+bjW/eFTu0yYNX47n0kbL34oTzF7+g0y8ywjM54daj23Zlc9xZwVWXveGTx8y 8iFVUjGKvD6nBTV/uB13YOyjwCFJH18zpOeKCCvxCWWiiiGJphIwzTN7llCn3++vL5gH KELYpyl+gyk0Bn6aAr32mafJ2MkA0qUKAbp4jzw1rC0hr+tltKYGA1CAQ1N0Npcc6Lzp +dWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=F74GV+UfcJPWjr/kYqlLW7gfe7QwHukYrgSw0dmF90g=; b=t2AWKj92Mdom8c+CUWJx7vS9rnNSGBwYUZDJmCCsXozoi7emdYhiBGfwQoknHQMQeS M8VF9kya95/QL00R3C+HUib2nzu0yoLoVTnIfIM37cUFTYpVjChgoiNTsqKjxU8DmTAW IP4CTq+IOXwfBJu/dPzZ7+DNsF/jJ9hX0kBVz8QuYtxNOS6wuLrXxKDQeLWKgg49HW1x 01eT/UJtG6dCLNX0R4Kc8f9/mKDrmHau9JAQP/Vo078EGHTT4RxeEJGLVlBlAVwdCRgE LtVrSFjzf6lSF0WElCjkolvp/DbVk5k3lSEa5vb2rRNpEtwJqpRw3/YxH2GUolz336pk LsMQ== 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 t19si2085927pgu.5.2019.01.04.10.27.14; Fri, 04 Jan 2019 10:27:30 -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 S1728419AbfADRHt (ORCPT + 99 others); Fri, 4 Jan 2019 12:07:49 -0500 Received: from foss.arm.com ([217.140.101.70]:46424 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726315AbfADRHs (ORCPT ); Fri, 4 Jan 2019 12:07:48 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C154CEBD; Fri, 4 Jan 2019 09:07:47 -0800 (PST) Received: from queper01-lin (queper01-lin.cambridge.arm.com [10.1.195.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8AED23F5D4; Fri, 4 Jan 2019 09:07:46 -0800 (PST) Date: Fri, 4 Jan 2019 17:07:41 +0000 From: Quentin Perret To: Chunyan Zhang Cc: Ingo Molnar , Peter Zijlstra , Vincent Wang , linux-kernel@vger.kernel.org, Chunyan Zhang Subject: Re: [PATCH] sched/cpufreq: calculate util / max firstly in get_next_freq() Message-ID: <20190104170741.h7bm6yivjf4z3tbd@queper01-lin> References: <1545634747-22401-1-git-send-email-chunyan.zhang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1545634747-22401-1-git-send-email-chunyan.zhang@unisoc.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Monday 24 Dec 2018 at 14:59:07 (+0800), Chunyan Zhang wrote: > 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 max, which are parameters used in get_next_freq(), will be cpu > frequency, instead of cpu util or 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 / max; This has moved to a different file recently -- see 938e5e4b0d15 ("sched/cpufreq: Prepare schedutil for Energy Aware Scheduling") so you probably want to rebase this patch :-) > > This patch will fix this overflow risk by calulating util / max firstly, > whether they be frequency or util. > > Signed-off-by: Vincent Wang > Signed-off-by: Chunyan Zhang > --- > kernel/sched/cpufreq_schedutil.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > index 3fffad3..7c372db1 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -166,8 +166,9 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy, > struct cpufreq_policy *policy = sg_policy->policy; > unsigned int freq = arch_scale_freq_invariant() ? > policy->cpuinfo.max_freq : policy->cur; > + unsigned int ratio = util * 100 / max; > > - freq = (freq + (freq >> 2)) * util / max; > + freq = (freq + (freq >> 2)) * ratio / 100; Maybe shift by SCHED_CAPACITY_SCALE instead of doing divisions ? Or you could also just keep the original structure and use proper u64 types instead of adding (useless) extra steps for 64 bits. Thanks, Quentin