From patchwork Mon Feb 8 11:39:27 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 61397 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp1384067lbl; Mon, 8 Feb 2016 03:41:25 -0800 (PST) X-Received: by 10.98.15.145 with SMTP id 17mr34992343pfp.19.1454931684429; Mon, 08 Feb 2016 03:41:24 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o12si46087221pfa.162.2016.02.08.03.41.24; Mon, 08 Feb 2016 03:41:24 -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; dkim=pass header.i=@linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752882AbcBHLlP (ORCPT + 30 others); Mon, 8 Feb 2016 06:41:15 -0500 Received: from mail-pa0-f43.google.com ([209.85.220.43]:34677 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752800AbcBHLlE (ORCPT ); Mon, 8 Feb 2016 06:41:04 -0500 Received: by mail-pa0-f43.google.com with SMTP id uo6so73854277pac.1 for ; Mon, 08 Feb 2016 03:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=OH6QEcu8PZmKeoqUOufyrL15ACRL4jLQpiJw7dChm/Q=; b=fzneschUIHwWWw+iKyt7OtKeHe7Q1FcxZk6yz00wlyI8vDjmYztMQtECysNSfcGSaf UUtHnn+wt5BjZ7vOSXGiIE6SbnwXY8H0imrdCAODQha+hY4yVjM+jHyyiSOqau7cq8hU 7fd7XJ1N4B6qGqI3Jp7P6rbRybdXUVaN+OzCI= 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=OH6QEcu8PZmKeoqUOufyrL15ACRL4jLQpiJw7dChm/Q=; b=ZKmp7JpBNrfEw0dZvoY8RPQlXQCCDPKXhJnR+KguQtBxsRvLsA/Aozvw8OXcLCTS3d 3f2DvU9p8lJQ1DJCLvGtpUNPYoW4/NgPzzHTGqIj+CqNSRNIUtDnyE0ORL0DGufjR4QH x3G/VwAljLWYbXZ7nVYraFpk2rygjL1cdWjXPFvfyz7BKTmyI843xuw9xe7pihOxYTRq CZ1tXPvE96C9ldWcy68D1gXA+IqPMeEeu6SKyoMwBTJ8MBC1ZS+V1vL++fdkGnSZxJ8b UUH7V9yPbJ/vbRvUsZJky6P+PsdtYV/PHrZkxSe3vmrkDOc0QNRw9dvCgqhMOfNXXF+t 06pA== X-Gm-Message-State: AG10YOT5Vi183sPk/rUGIhb7E31GvaZDBBb8eHVm7PsiiCKIhV4UJ9ZRkqgkdhn2t4F3wjaZ X-Received: by 10.66.97.8 with SMTP id dw8mr28155612pab.39.1454931664475; Mon, 08 Feb 2016 03:41:04 -0800 (PST) Received: from localhost ([122.172.22.246]) by smtp.gmail.com with ESMTPSA id y15sm10197316pfi.16.2016.02.08.03.41.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2016 03:41:04 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , juri.lelli@arm.com Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, skannan@codeaurora.org, peterz@infradead.org, mturquette@baylibre.com, steve.muckle@linaro.org, vincent.guittot@linaro.org, morten.rasmussen@arm.com, dietmar.eggemann@arm.com, shilpa.bhat@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, Viresh Kumar Subject: [PATCH V3 13/13] cpufreq: conservative: Update sample_delay_ns immediately Date: Mon, 8 Feb 2016 17:09:27 +0530 Message-Id: <6758a7bf2d6facc288bef632c5d47e7e2c5ba05b.1454931189.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.7.1.370.gb2aa7f8 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ondemand governor already updates sample_delay_ns immediately on updates to sampling rate, but conservative isn't doing that. It was left out earlier as the code has been really complex to get that done easily. But now things are sorted out very well, and we can follow the same for conservative governor as well. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq_governor.c | 30 +++++++++++++++++++++++++++--- drivers/cpufreq/cpufreq_governor.h | 1 - drivers/cpufreq/cpufreq_ondemand.c | 38 -------------------------------------- 3 files changed, 27 insertions(+), 42 deletions(-) -- 2.7.1.370.gb2aa7f8 diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index e267acc67067..3f4338bdb3aa 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++ b/drivers/cpufreq/cpufreq_governor.c @@ -29,7 +29,7 @@ EXPORT_SYMBOL_GPL(dbs_data_mutex); static ssize_t store_sampling_rate(struct dbs_data *dbs_data, const char *buf, size_t count) { - struct dbs_governor *gov = dbs_data->gov; + struct policy_dbs_info *policy_dbs; unsigned int rate; int ret; ret = sscanf(buf, "%u", &rate); @@ -38,8 +38,32 @@ static ssize_t store_sampling_rate(struct dbs_data *dbs_data, const char *buf, dbs_data->sampling_rate = max(rate, dbs_data->min_sampling_rate); - if (gov->update_sampling_rate) - gov->update_sampling_rate(dbs_data); + /* + * We are operating under dbs_data->mutex and so the list and its + * entries can't be freed concurrently. + */ + list_for_each_entry(policy_dbs, &dbs_data->policy_dbs_list, list) { + mutex_lock(&policy_dbs->timer_mutex); + /* + * On 32-bit architectures this may race with the + * sample_delay_ns read in dbs_update_util_handler(), but that + * really doesn't matter. If the read returns a value that's + * too big, the sample will be skipped, but the next invocation + * of dbs_update_util_handler() (when the update has been + * completed) will take a sample. If the returned value is too + * small, the sample will be taken immediately, but that isn't a + * problem, as we want the new rate to take effect immediately + * anyway. + * + * If this runs in parallel with dbs_work_handler(), we may end + * up overwriting the sample_delay_ns value that it has just + * written, but the difference should not be too big and it will + * be corrected next time a sample is taken, so it shouldn't be + * significant. + */ + gov_update_sample_delay(policy_dbs, dbs_data->sampling_rate); + mutex_unlock(&policy_dbs->timer_mutex); + } return count; } diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h index b740633c2fbe..127982f6d869 100644 --- a/drivers/cpufreq/cpufreq_governor.h +++ b/drivers/cpufreq/cpufreq_governor.h @@ -212,7 +212,6 @@ struct dbs_governor { void (*exit)(struct dbs_data *dbs_data, bool notify); bool (*invalid_up_threshold)(struct dbs_data *dbs_data, unsigned int threshold); bool (*invalid_sampling_down_factor)(unsigned int factor); - void (*update_sampling_rate)(struct dbs_data *dbs_data); void (*update_sampling_down_factor)(struct dbs_data *dbs_data); void (*update_ignore_nice_load)(struct dbs_data *dbs_data); diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c index f72087bc8302..1e17f6ffdf42 100644 --- a/drivers/cpufreq/cpufreq_ondemand.c +++ b/drivers/cpufreq/cpufreq_ondemand.c @@ -221,43 +221,6 @@ static unsigned int od_dbs_timer(struct cpufreq_policy *policy) /************************** sysfs interface ************************/ static struct dbs_governor od_dbs_gov; -/** - * update_sampling_rate - update sampling rate effective immediately if needed. - * @new_rate: new sampling rate - */ -static void update_sampling_rate(struct dbs_data *dbs_data) -{ - struct policy_dbs_info *policy_dbs; - unsigned int new_rate = dbs_data->sampling_rate; - - /* - * We are operating under dbs_data->mutex and so the list and its - * entries can't be freed concurrently. - */ - list_for_each_entry(policy_dbs, &dbs_data->policy_dbs_list, list) { - mutex_lock(&policy_dbs->timer_mutex); - /* - * On 32-bit architectures this may race with the - * sample_delay_ns read in dbs_update_util_handler(), but that - * really doesn't matter. If the read returns a value that's - * too big, the sample will be skipped, but the next invocation - * of dbs_update_util_handler() (when the update has been - * completed) will take a sample. If the returned value is too - * small, the sample will be taken immediately, but that isn't a - * problem, as we want the new rate to take effect immediately - * anyway. - * - * If this runs in parallel with dbs_work_handler(), we may end - * up overwriting the sample_delay_ns value that it has just - * written, but the difference should not be too big and it will - * be corrected next time a sample is taken, so it shouldn't be - * significant. - */ - gov_update_sample_delay(policy_dbs, new_rate); - mutex_unlock(&policy_dbs->timer_mutex); - } -} - static bool invalid_up_threshold(struct dbs_data *dbs_data, unsigned int threshold) { @@ -425,7 +388,6 @@ static struct dbs_governor od_dbs_gov = { .get_cpu_dbs_info_s = get_cpu_dbs_info_s, .gov_dbs_timer = od_dbs_timer, .gov_check_cpu = od_check_cpu, - .update_sampling_rate = update_sampling_rate, .invalid_up_threshold = invalid_up_threshold, .invalid_sampling_down_factor = invalid_sampling_down_factor, .update_sampling_down_factor = update_sampling_down_factor,