From patchwork Mon Aug 14 09:20:16 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 109963 Delivered-To: patch@linaro.org Received: by 10.140.95.78 with SMTP id h72csp4091355qge; Mon, 14 Aug 2017 02:20:29 -0700 (PDT) X-Received: by 10.84.245.9 with SMTP id i9mr27040177pll.312.1502702429792; Mon, 14 Aug 2017 02:20:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502702429; cv=none; d=google.com; s=arc-20160816; b=dmECuUgdpLbDo3aJEvXW+BpuR0QPOLNGZ3JbY8pQ6E9uJ+M/usRZ6S7yXoFDFNOVgJ LxLZkTGOUzM8dX+772r7ADwFNWy1d19bD/PvDkdPY+sPxzwC9TFxOP3IawhqCtkDe3gx L/+GynmQQ5vqHvxbMTVcaLnKo8IxmpprDTtDosQNH4fhH0Cs1qZQYq0H7Ttze5+u5qyJ tSKru9unhju9uZz0UAJ64JQasMmIcFqJifanxFbttc2+cGiU4j2U8Om7Vj2elq4XJXKV 35y/DZTAC4L+Z4fsHARTfeQc88TIhD5c+9eiP1fJYcpv5FsntehMf2k49Aj1HmQV8qFK gigA== 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:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=yT8PozbmvJrUWV1M3feTf/8MHsjhm4mhPE3V2cBgc+Y=; b=Np3W7TDpmctnBwFtyHqe6ToAjPJllPxp2Z0iOtuhj/TvUO+9gbSSzwebi94pK3iByc 381bhn4M9IZEYKvyPgaNgF/BTVb9sa6v3zglCY1STdpFPO3mAOZ7Bns3VDv0A5Mm2cYr lHkbUxoR/pZWtYUmOuF1hqxhiobrvASLVzczCcc7mVluuALJSwLO31Z49AMuWdhS/vAh MgAVOm4jxSumeQTiUeyH/mD1bXHkJUKBxg2cge4BKrv8vn2ehsgIbud+msp9cnTEZ7OW h+G734xSvuQUIwrziU3ZwRHuW3I/BDcOsfBHVcxZzmD6houq0z7fTTrezRkLBZm5yMxn Jd5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LhT0fC/C; 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 r12si4449581plj.541.2017.08.14.02.20.29; Mon, 14 Aug 2017 02:20:29 -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=LhT0fC/C; 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 S1752654AbdHNJUZ (ORCPT + 25 others); Mon, 14 Aug 2017 05:20:25 -0400 Received: from mail-pg0-f42.google.com ([74.125.83.42]:33149 "EHLO mail-pg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752615AbdHNJUW (ORCPT ); Mon, 14 Aug 2017 05:20:22 -0400 Received: by mail-pg0-f42.google.com with SMTP id u5so43687868pgn.0 for ; Mon, 14 Aug 2017 02:20:22 -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; bh=yT8PozbmvJrUWV1M3feTf/8MHsjhm4mhPE3V2cBgc+Y=; b=LhT0fC/CU3pZxD4bMvEO7Q6VATko7MPUyCg6FbxbPF2t+fpWlGmTqV4XrGINSzfl8P uAg2ypK5iTz8i5zbIPOy6mXCO9SuexeuxsSk9SMW0seGQ+wkYcREmOxksGqzKOiu+jdK QlspUneEb9R4gcLTlM9JBp7GEf/2siPhIoCNU= 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; bh=yT8PozbmvJrUWV1M3feTf/8MHsjhm4mhPE3V2cBgc+Y=; b=NV7uj1nZfTwRlnw4LO5OCAAd3LV8aENWW5LL4N4v5o7WcHN27EJz/X4uHAN5569dml +8AK/dbcA+eq7lXwwv4BeOtNbsP9R7CAGipYzNkrRPB8deSlzfXRx7Tjd8Pkp3dqkefV sAavgB7M9eiJyL3WqgLQiavlfRHvLJPgyjPxb+QNGQ0pU1Ap0NyhozeBolHMVKmCkUTa eVJ6/jEzuloMJzP9Y5ki2v6tWk/K8p8mZrfqxSNp46jgGHUNGJ+3pEQgU2Kkz6WaK3eO XZpM2CAvhG8HE/y0cqHKX/YfKvdilDhLGbNpWSRs0wbcqwIGASsnfqFjQIafewgwquVy ce2A== X-Gm-Message-State: AHYfb5jKdBHtHT3hL87fmM5ZNG2HJhRLPZWQscX2g2g5GmqvXh3fFVX1 fflk8NF5+9oNtdiF X-Received: by 10.98.14.93 with SMTP id w90mr24681999pfi.298.1502702422207; Mon, 14 Aug 2017 02:20:22 -0700 (PDT) Received: from localhost ([122.172.110.130]) by smtp.gmail.com with ESMTPSA id l5sm13313889pfg.50.2017.08.14.02.20.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 02:20:20 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Ingo Molnar , Peter Zijlstra Cc: Viresh Kumar , linux-pm@vger.kernel.org, Vincent Guittot , Juri.Lelli@arm.com, joelaf@google.com, linux-kernel@vger.kernel.org Subject: [PATCH V2 2/2] cpufreq: schedutil: Always process remote callback with slow switching Date: Mon, 14 Aug 2017 14:50:16 +0530 Message-Id: X-Mailer: git-send-email 2.7.4 In-Reply-To: <2a395ea76235dce00828172a1129c46bf87a79c8.1502338812.git.viresh.kumar@linaro.org> References: <2a395ea76235dce00828172a1129c46bf87a79c8.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 --- V2: s/policy/sg_policy->policy/, missed updating the commit with local updates earlier, noticed that just now. kernel/sched/cpufreq_schedutil.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) -- 2.7.4 diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 504d0752f8f2..9209d83ecdcf 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 (sg_policy->policy->fast_switch_enabled && + !cpufreq_can_do_remote_dvfs(sg_policy->policy)) return false; if (sg_policy->work_in_progress)