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: 9583949 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id D81EF602A7 for ; Tue, 21 Feb 2017 07:10:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BE1F7288DA for ; Tue, 21 Feb 2017 07:10:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B2E1D288E5; Tue, 21 Feb 2017 07:10:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2D2DE288DA for ; Tue, 21 Feb 2017 07:10:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751069AbdBUEpw (ORCPT ); Mon, 20 Feb 2017 23:45:52 -0500 Received: from mail-pg0-f49.google.com ([74.125.83.49]:35435 "EHLO mail-pg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750992AbdBUEpa (ORCPT ); Mon, 20 Feb 2017 23:45:30 -0500 Received: by mail-pg0-f49.google.com with SMTP id b129so29211358pgc.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=e/oJHZvFHipsQ1sogJ0bV2emqFQTd6yz2WfThJxd6FTR/9BA8LHJjGgxzmrISMgEXW 6vJqcn3Ew6r13UUwjMwNuNMn7x4HPBBKyHRIzPGXa/WvpTrETbySNyVmyOJc/YKCo0hN GZqb0/xqheQKPtEyh+RpMQ44rKuTTpP75U8hxwntcAQ452rUQov29mJB0s44XQfsXzsi utmJ1UdQR+nQ1FXu6AN/gS4m4Ae8VLv+Rh7lyUbeVIP5PnBbEGzpgKJDsaX0W1PKx1gD r676pk7Rjhtc92ajeQEsUz5134ucUgE2IGCAYipFRg/cF05Epp804cY6Pw/u4bBYxTkI hK0w== X-Gm-Message-State: AMke39nkh8+mT67mi9qmDDr4p9k9/zhKrmrivhHGL7jaF/8CGHN/IY9fBt5i55aOcFjyC3ds 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-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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(-) 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); }