From patchwork Tue Feb 21 04:45:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 94251 Delivered-To: patch@linaro.org Received: by 10.140.20.99 with SMTP id 90csp320871qgi; Mon, 20 Feb 2017 23:08:45 -0800 (PST) X-Received: by 10.84.211.35 with SMTP id b32mr37817241pli.113.1487660925522; Mon, 20 Feb 2017 23:08:45 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r59si21087927plb.97.2017.02.20.23.08.45; Mon, 20 Feb 2017 23:08:45 -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; dkim=pass header.i=@linaro.org; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751208AbdBUEpx (ORCPT + 25 others); Mon, 20 Feb 2017 23:45:53 -0500 Received: from mail-pg0-f48.google.com ([74.125.83.48]:35435 "EHLO mail-pg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750964AbdBUEpa (ORCPT ); Mon, 20 Feb 2017 23:45:30 -0500 Received: by mail-pg0-f48.google.com with SMTP id b129so29211356pgc.2 for ; Mon, 20 Feb 2017 20:45:30 -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; bh=tpGo2X6S4cUTgu86r4oRmJPsz6BLpSDSirr255cyWss=; b=KgABXJZu6+aPMHNFU4yINcWrwGnH6+hsd4DbIRDd6DHAj98bvNXEqKcHEARP2nQ1FK LHhDnQOVHFsdkcgRdUsdfBlH7DDZKKaq5lZKs/kdPz10vpHiq0LcS4PaudzVVzeqxmgC 0tczoOa4Pl6/nZXfbn5MpfXupshxLmnxEfI9I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=tpGo2X6S4cUTgu86r4oRmJPsz6BLpSDSirr255cyWss=; b=AsrYZSseNpy8ytN8iFnikp1uCe+ipldhz78ygEnWzapvo4tb5LabpavIOczgCzjxm3 40qZ8JLIUNpvOGTiQpGQHYK2dE8KCwXP4reoB1hNCl9pf0JQNBIgKruvnyv2qMqEtEG5 pEhfD9tH2K1EnUbQ0BkYlhIBXND7NHliXpM+8Ldi4DnXBvJrLa1q3ESBkzdpbHOdAHeV WTV1rqEpgXBII0GSXDuj4f4KYLEXP59mIbccVvS4dEMG8aEMU+Fh+ne/d1wVveCt4tPi Qr7jJm1z37OrNeijxkZKHXr3w3qtYwBzYN+OOCtDFlhReTKFCl10l0hgM9N67XEe2QFr /xWQ== X-Gm-Message-State: AMke39leVdwYJYZPKvzetgutDfknUB8N48GIHQz8njphsClId2I/Baqc9kuXtqghKuoisuoI X-Received: by 10.99.146.7 with SMTP id o7mr32119934pgd.6.1487652330003; Mon, 20 Feb 2017 20:45:30 -0800 (PST) Received: from localhost ([122.172.165.189]) by smtp.gmail.com with ESMTPSA id 84sm7561827pgh.21.2017.02.20.20.45.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Feb 2017 20:45:28 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , Ingo Molnar , Peter Zijlstra Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , eas-dev@lists.linaro.org, Viresh Kumar Subject: [PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable Date: Tue, 21 Feb 2017 10:15:18 +0530 Message-Id: <250f484b4fec4922601f18e719f587aa40c8b220.1487651965.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.7.1.410.g6faf27b Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The rate_limit_us tunable is intended to reduce the possible overhead from running the schedutil governor. However, that overhead can be divided into two separate parts: the governor computations and the invocation of the scaling driver to set the CPU frequency. The latter is where the real overhead comes from. The former is much less expensive in terms of execution time and running it every time the governor callback is invoked by the scheduler, after rate_limit_us interval has passed since the last frequency update, would not be a problem. For this reason, redefine the rate_limit_us tunable so that it means the minimum time that has to pass between two consecutive invocations of the scaling driver by the schedutil governor (to set the CPU frequency). Signed-off-by: Viresh Kumar --- V1->V2: Update $subject and commit log (Rafael) kernel/sched/cpufreq_schedutil.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.7.1.410.g6faf27b diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index fd4659313640..306d97e7b57c 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -92,14 +92,13 @@ static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time, { struct cpufreq_policy *policy = sg_policy->policy; - sg_policy->last_freq_update_time = time; - if (policy->fast_switch_enabled) { if (sg_policy->next_freq == next_freq) { trace_cpu_frequency(policy->cur, smp_processor_id()); return; } sg_policy->next_freq = next_freq; + sg_policy->last_freq_update_time = time; next_freq = cpufreq_driver_fast_switch(policy, next_freq); if (next_freq == CPUFREQ_ENTRY_INVALID) return; @@ -108,6 +107,7 @@ static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time, trace_cpu_frequency(next_freq, smp_processor_id()); } else if (sg_policy->next_freq != next_freq) { sg_policy->next_freq = next_freq; + sg_policy->last_freq_update_time = time; sg_policy->work_in_progress = true; irq_work_queue(&sg_policy->irq_work); }