From patchwork Tue Oct 13 08:09:02 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 7381911 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 9DF4B9F1D5 for ; Tue, 13 Oct 2015 08:11:30 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BD5B720747 for ; Tue, 13 Oct 2015 08:11:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D33D82073B for ; Tue, 13 Oct 2015 08:11:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752757AbbJMIJc (ORCPT ); Tue, 13 Oct 2015 04:09:32 -0400 Received: from mail-pa0-f47.google.com ([209.85.220.47]:33344 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752549AbbJMIJ3 (ORCPT ); Tue, 13 Oct 2015 04:09:29 -0400 Received: by pabrc13 with SMTP id rc13so14379736pab.0 for ; Tue, 13 Oct 2015 01:09:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=AT3X5CLrSrR7TXlBztlwVIsIqiNx90yKAjSKMpwCoy4=; b=GoXNqlphP2IEIgYVLOeeTGGmH3V6m/AgI09s7Bi6ME+vLSRzzynorChHkPlafbL2n6 lRDcYaQwL0hq2SkHlhwpbtErOhQfoLoSBuE05JWGEo6qkKM15mf7kef2A/qcrewNZHiC FSNCYHWmX03gZW9ckby07vJM+vZQz3lFDOBfd+/cuRiItIGSJfLskyQz/molFvip3VBZ DggB2NA4gQGkCZxUXrqIkUFCQeVoz4q9OV3LNisuMcSdz1S6lojl+6l7YC9LdEmxSQrC 83BOKL4UDSsUuos70RAJ6DjijE8O0JMkE0Oay9fZWnRkTvxudXOvgcxGxP1LGD+Qib24 mCbQ== X-Gm-Message-State: ALoCoQn3Ptx6LU4BUwMeE3W54ZwohXOt/d/4efiyMAvsgsgp+LlMCaqZKTRjjHqsToRAnfiBt8VD X-Received: by 10.66.100.166 with SMTP id ez6mr38791800pab.78.1444723769394; Tue, 13 Oct 2015 01:09:29 -0700 (PDT) Received: from localhost ([223.227.239.124]) by smtp.gmail.com with ESMTPSA id oo2sm2215564pbb.86.2015.10.13.01.09.27 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 13 Oct 2015 01:09:28 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, Viresh Kumar , linux-kernel@vger.kernel.org (open list) Subject: [PATCH V3 2/5] cpufreq: ondemand: update sampling rate immediately Date: Tue, 13 Oct 2015 13:39:02 +0530 Message-Id: <1746c301a8f0a94578f550026cf41e532e6e0f41.1444723240.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.4.0 In-Reply-To: References: In-Reply-To: References: Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP We are immediately updating sampling rate for already queued-works, only if the new expiry is lesser than the old one. But what about the case, where the user doesn't want frequent events and want to increase sampling time immediately? Shouldn't we cancel the works (and so their interrupts) on all policy->cpus (which might occur very shortly). This patch removes this special case and simplifies code by immediately updating the expiry. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq_ondemand.c | 25 ++++--------------------- 1 file changed, 4 insertions(+), 21 deletions(-) diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c index 03ac6ce54042..bf0511a9735c 100644 --- a/drivers/cpufreq/cpufreq_ondemand.c +++ b/drivers/cpufreq/cpufreq_ondemand.c @@ -231,17 +231,8 @@ static unsigned int od_dbs_timer(struct cpu_dbs_info *cdbs, static struct common_dbs_data od_dbs_cdata; /** - * update_sampling_rate - update sampling rate effective immediately if needed. + * update_sampling_rate - update sampling rate immediately. * @new_rate: new sampling rate - * - * If new rate is smaller than the old, simply updating - * dbs_tuners_int.sampling_rate might not be appropriate. For example, if the - * original sampling_rate was 1 second and the requested new sampling rate is 10 - * ms because the user needs immediate reaction from ondemand governor, but not - * sure if higher frequency will be required or not, then, the governor may - * change the sampling rate too late; up to 1 second later. Thus, if we are - * reducing the sampling rate, we need to make the new value effective - * immediately. */ static void update_sampling_rate(struct dbs_data *dbs_data, unsigned int new_rate) @@ -255,7 +246,6 @@ static void update_sampling_rate(struct dbs_data *dbs_data, for_each_online_cpu(cpu) { struct cpufreq_policy *policy; struct od_cpu_dbs_info_s *dbs_info; - unsigned long next_sampling, appointed_at; policy = cpufreq_cpu_get(cpu); if (!policy) @@ -270,16 +260,9 @@ static void update_sampling_rate(struct dbs_data *dbs_data, if (!delayed_work_pending(&dbs_info->cdbs.dwork)) continue; - next_sampling = jiffies + usecs_to_jiffies(new_rate); - appointed_at = dbs_info->cdbs.dwork.timer.expires; - - if (time_before(next_sampling, appointed_at)) { - cancel_delayed_work_sync(&dbs_info->cdbs.dwork); - - gov_queue_work(dbs_data, policy, - usecs_to_jiffies(new_rate), true); - - } + cancel_delayed_work_sync(&dbs_info->cdbs.dwork); + gov_queue_work(dbs_data, policy, usecs_to_jiffies(new_rate), + true); } }