From patchwork Thu Aug 10 04:20:56 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 109777 Delivered-To: patch@linaro.org Received: by 10.140.95.78 with SMTP id h72csp1806700qge; Wed, 9 Aug 2017 21:21:21 -0700 (PDT) X-Received: by 10.99.111.204 with SMTP id k195mr10278206pgc.20.1502338881563; Wed, 09 Aug 2017 21:21:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502338881; cv=none; d=google.com; s=arc-20160816; b=pDfLUxRkLYKT1nyAkPlrP50OIIABfQH/LV40dp+HwhaS1f4E8u38E6XMMey9/ZisC5 eHEOqTV3dBCXDXzLDbh+Fo7x3xWcJNKjMV4M9neN0IoZdxsihk0lYtPfi9sjoSeORh7n bjD56JItYm0ZzYw3QFIxuhf3jelIB2hY5mYK5Ouq0idtGXILrTgh34PpZcSqTmYKyzDr YQ/mWdacSPGrpfEhZaNPZXznS5UREpE3Pgv7kHQWWlumnx4sFWBPFqh4SIGHZZJq6lmV Nug0jHv/cxXw1KmVOLl+Fshd6CH0ShnIQj+/R4vwR6gdG2h8Weh4pFdsVo+izolc0hkR 09aA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=uFh8qDhV6rYK7E+NpMzGfllqaccHtmN/OgFSGUIh3O8=; b=pkQlpD2ELIuMyMdRNkD7sDX8jw7NprodLsp4N4FbAZP3s8hP5OxNo6va2hIFfG5V5B pEpao4mPLzk9YyAFynB+o3bce+YYCexpDCVHksExiW4yakovXekxMXZEh+IHYFQzsu0N S4b6c0PjFuX5lzK+RbRBOcNJ/tgBUXILOUZ+ZqhcmIccflFCuhdoybjjdxwS4Qak2Jm4 t9KPABEm21CuWitySQErfQUSyIxI4XmKBdHgZk6on6/B3JZdPjfiEz8sF3eqwgIHtZgx QRq4I3LYeIyHAiO5oJ5RMgpIUTM603PT7DFYBGOWD55Zbp0bsEx0wnNis2CJLMYWNNTZ OIsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LeBfvuxf; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b5si3354947pgc.359.2017.08.09.21.21.21; Wed, 09 Aug 2017 21:21:21 -0700 (PDT) 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 header.s=google header.b=LeBfvuxf; 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 S1752225AbdHJEVQ (ORCPT + 25 others); Thu, 10 Aug 2017 00:21:16 -0400 Received: from mail-pf0-f172.google.com ([209.85.192.172]:34656 "EHLO mail-pf0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752169AbdHJEVM (ORCPT ); Thu, 10 Aug 2017 00:21:12 -0400 Received: by mail-pf0-f172.google.com with SMTP id o86so36265249pfj.1 for ; Wed, 09 Aug 2017 21:21:12 -0700 (PDT) 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=uFh8qDhV6rYK7E+NpMzGfllqaccHtmN/OgFSGUIh3O8=; b=LeBfvuxf9ugxgzHAHPNxxfYe+CGK0RRtfGls4VB85tSvqBC2bOjQ+modQVgNxQTG15 35fH9Graf1xmhjv4DgLSmCS6ATJFs9oM9LrRzjevQjjMgu3lpjnERogb2eaZM6J4CGZy jkR8jLvFN/ohbbfmZN/4in5fqWpUF+6YJyaEc= 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:in-reply-to :references:in-reply-to:references; bh=uFh8qDhV6rYK7E+NpMzGfllqaccHtmN/OgFSGUIh3O8=; b=chNCjGx4H6kvyOdK9UyPiO103+pCQiCrsEen6+FDNmtWmLp0BlGeNtFTyyxjEd/ZsX cTeNv85LjMzTd2H5NbWji77D6q7Cq3MlMIGC6ghY8JbAAYx7y4mb0iNxcnzT0RklELcN dnE8OXki2gPE4WMF2yHK7DSUpvcsHeWfCfqXbsUnB7NDFsRSehExtENjzggHlT4sgZJH BgtrqwguRxqQAijUOrY0YI6usxniGZfQW1hGf1FE1NCGJs4jNlBalxoYKEzsAb6RQWcu wnj4ftD5bqb7Be2ymMvfIbWGgv+p3AQhREhz0P2C+Clnxsl9/hkkRnAUrhDIrWzi963q dBaA== X-Gm-Message-State: AHYfb5hV5xsg7RbS3o9uHYihaNrWr1p2SfmNkmudDdT1EoxCnVyjW9I8 jWQoRYFlHwOY0dEl X-Received: by 10.99.182.5 with SMTP id j5mr9969617pgf.137.1502338872251; Wed, 09 Aug 2017 21:21:12 -0700 (PDT) Received: from localhost ([122.172.24.241]) by smtp.gmail.com with ESMTPSA id t199sm7587760pgb.30.2017.08.09.21.21.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2017 21:21:11 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Ingo Molnar , Peter Zijlstra Cc: Viresh Kumar , linux-pm@vger.kernel.org, Vincent Guittot , Juri Lelli , joelaf@google.com, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] cpufreq: schedutil: Always process remote callback with slow switching Date: Thu, 10 Aug 2017 09:50:56 +0530 Message-Id: <2a395ea76235dce00828172a1129c46bf87a79c8.1502338812.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.13.0.71.gd7076ec9c9cb In-Reply-To: <8dd297a6ed05ed3f6c33aeb3059e71a1d270c530.1502338812.git.viresh.kumar@linaro.org> References: <8dd297a6ed05ed3f6c33aeb3059e71a1d270c530.1502338812.git.viresh.kumar@linaro.org> In-Reply-To: <8dd297a6ed05ed3f6c33aeb3059e71a1d270c530.1502338812.git.viresh.kumar@linaro.org> References: <8dd297a6ed05ed3f6c33aeb3059e71a1d270c530.1502338812.git.viresh.kumar@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The frequency update from the utilization update handlers can be divided into two parts: (A) Finding the next frequency (B) Updating the frequency While any CPU can do (A), (B) can be restricted to a group of CPUs only, depending on the current platform. For platforms where fast cpufreq switching is possible, both (A) and (B) are always done from the same CPU and that CPU should be capable of changing the frequency of the target CPU. But for platforms where fast cpufreq switching isn't possible, after doing (A) we wake up a kthread which will eventually do (B). This kthread is already bound to the right set of CPUs, i.e. only those which can change the frequency of CPUs of a cpufreq policy. And so any CPU can actually do (A) in this case, as the frequency is updated from the right set of CPUs only. Check cpufreq_can_do_remote_dvfs() only for the fast switching case. Signed-off-by: Viresh Kumar --- kernel/sched/cpufreq_schedutil.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) -- 2.13.0.71.gd7076ec9c9cb diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 504d0752f8f2..cb21cb70e7dc 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -84,13 +84,18 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time) * * However, drivers cannot in general deal with cross-cpu * requests, so while get_next_freq() will work, our - * sugov_update_commit() call may not. + * sugov_update_commit() call may not for the fast switching platforms. * * Hence stop here for remote requests if they aren't supported * by the hardware, as calculating the frequency is pointless if * we cannot in fact act on it. + * + * For the slow switching platforms, the kthread is always scheduled on + * the right set of CPUs and any CPU can find the next frequency and + * schedule the kthread. */ - if (!cpufreq_can_do_remote_dvfs(sg_policy->policy)) + if (policy->fast_switch_enabled && + !cpufreq_can_do_remote_dvfs(sg_policy->policy)) return false; if (sg_policy->work_in_progress)