From patchwork Tue Feb 9 03:46:18 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 61487 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp1808442lbl; Mon, 8 Feb 2016 19:48:46 -0800 (PST) X-Received: by 10.67.3.170 with SMTP id bx10mr47340273pad.34.1454989726707; Mon, 08 Feb 2016 19:48:46 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id fi15si50907211pac.191.2016.02.08.19.48.46; Mon, 08 Feb 2016 19:48:46 -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 S1756288AbcBIDsc (ORCPT + 30 others); Mon, 8 Feb 2016 22:48:32 -0500 Received: from mail-pa0-f42.google.com ([209.85.220.42]:36781 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755883AbcBIDrw (ORCPT ); Mon, 8 Feb 2016 22:47:52 -0500 Received: by mail-pa0-f42.google.com with SMTP id yy13so84203964pab.3 for ; Mon, 08 Feb 2016 19:47:52 -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=6p0ej6Vsqb1zIk3vVFEYje6HxuGAuboplOC6DmQm3X0=; b=RZDdyhDi9ZtVRj6BhYfetqFhsgRzYa4BfwZe5wBW3Exhuf0SqTO33P6JPosL+izmLo mjF9H30cAePF1YlWpjfxEibzTM6WCtb2l4xzY+4iTJY4bwLtedyLPW7GIWgJHwGw7s77 Hr5QQcMfevLkB3MBA1yMraKmu6gLNhKp9f0Es= 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=6p0ej6Vsqb1zIk3vVFEYje6HxuGAuboplOC6DmQm3X0=; b=nGZ2mL85+EIUg3fHmsPzxTBVXm/2pU5znVC/qxpudAqUQ399ZhcuyYWf/8kaCrGHn9 0cljXA20HFAI6t2QTgpGZcIxBD/MUpWHrbsjGL687xhMTsXo5f6idVdOg6Q7pFB7gxfE A0EA33LpdKBIycaGffFDJ4n5zgfHFcf2CYyy8Sdbpe5KXAArOA4K48XoYKCDAQhSgSu9 dVeA4T+AEzVnjU3Bif/5w8Md/AdyCtxrDNS215ZM1JXez2HfXh1lvk967/SXOwkbIPUJ 5A4RcDGpfe1kuXPb0FFymGMLH9Bo5rcfJ+lNdIv7Ah5unAZRM3o3CUvzQ2jMS8rg00k3 6G2Q== X-Gm-Message-State: AG10YOReWAtPwBYq0gmoVB7sU3v9x4YlbC3GM4YicGNUBn4PCO7rHWx1VUeCyW4IErIRjefa X-Received: by 10.66.162.9 with SMTP id xw9mr47188461pab.46.1454989672334; Mon, 08 Feb 2016 19:47:52 -0800 (PST) Received: from localhost ([122.172.22.246]) by smtp.gmail.com with ESMTPSA id z5sm46551534pas.29.2016.02.08.19.47.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2016 19:47:51 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , juri.lelli@arm.com Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, shilpa.bhat@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, Viresh Kumar Subject: [PATCH V4 6/7] cpufreq: conservative: Update sample_delay_ns immediately Date: Tue, 9 Feb 2016 09:16:18 +0530 Message-Id: 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 Tested-by: Juri Lelli Tested-by: Shilpasri G Bhat --- drivers/cpufreq/cpufreq_governor.c | 49 ++++++++++++++++++++++++++++++++--- drivers/cpufreq/cpufreq_governor.h | 1 - drivers/cpufreq/cpufreq_ondemand.c | 52 -------------------------------------- 3 files changed, 46 insertions(+), 56 deletions(-) -- 2.7.1.370.gb2aa7f8 diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index 464f346815e0..c0f9151e1045 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++ b/drivers/cpufreq/cpufreq_governor.c @@ -26,10 +26,29 @@ DEFINE_MUTEX(dbs_data_mutex); EXPORT_SYMBOL_GPL(dbs_data_mutex); /* Common sysfs tunables */ +/** + * update_sampling_rate - update sampling rate effective immediately if needed. + * + * If new rate is smaller than the old, simply updating + * dbs.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. + * + * On the other hand, if new rate is larger than the old, then we may evaluate + * the load too soon, and it might we worth updating sample_delay_ns then as + * well. + * + * This must be called with dbs_data->mutex held, otherwise traversing + * policy_dbs_list isn't safe. + */ 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 +57,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 8aff218f73a4..9ab1a05712d8 100644 --- a/drivers/cpufreq/cpufreq_governor.h +++ b/drivers/cpufreq/cpufreq_governor.h @@ -211,7 +211,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 caef7c9f631d..d9f323f150c4 100644 --- a/drivers/cpufreq/cpufreq_ondemand.c +++ b/drivers/cpufreq/cpufreq_ondemand.c @@ -221,57 +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. - * - * If new rate is smaller than the old, simply updating - * dbs.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. - * - * On the other hand, if new rate is larger than the old, then we may evaluate - * the load too soon, and it might we worth updating sample_delay_ns then as - * well. - * - * This must be called with dbs_data->mutex held, otherwise traversing - * policy_dbs_list isn't safe. - */ -static void update_sampling_rate(struct dbs_data *dbs_data) -{ - struct policy_dbs_info *policy_dbs; - - /* - * 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); - } -} - static bool invalid_up_threshold(struct dbs_data *dbs_data, unsigned int threshold) { @@ -438,7 +387,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,