Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752551AbdGMPRg (ORCPT ); Thu, 13 Jul 2017 11:17:36 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:36811 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751267AbdGMPRe (ORCPT ); Thu, 13 Jul 2017 11:17:34 -0400 MIME-Version: 1.0 In-Reply-To: References: From: "Rafael J. Wysocki" Date: Thu, 13 Jul 2017 17:17:19 +0200 X-Google-Sender-Auth: QPMOCkU7Xhp3O6_rFEzo-DlWfAM Message-ID: Subject: Re: [PATCH V3 0/3] sched: cpufreq: Allow remote callbacks To: Viresh Kumar Cc: Rafael Wysocki , Linux PM , Vincent Guittot , Steve Muckle , Juri Lelli , Morten Rasmussen , Patrick Bellasi , eas-dev@lists.linaro.org, Ingo Molnar , Len Brown , Linux Kernel Mailing List , Peter Zijlstra , Srinivas Pandruvada Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2426 Lines: 56 On Thu, Jul 13, 2017 at 8:44 AM, Viresh Kumar wrote: > Hi, > > With Android UI and benchmarks the latency of cpufreq response to > certain scheduling events can become very critical. Currently, callbacks > into schedutil are only made from the scheduler if the target CPU of the > event is the same as the current CPU. This means there are certain > situations where a target CPU may not run schedutil for some time. > > One testcase to show this behavior is where a task starts running on > CPU0, then a new task is also spawned on CPU0 by a task on CPU1. If the > system is configured such that new tasks should receive maximum demand > initially, this should result in CPU0 increasing frequency immediately. > Because of the above mentioned limitation though this does not occur. > This is verified using ftrace with the sample [1] application. > > Maybe the ideal solution is to always allow remote callbacks but that > has its own challenges: > > o There is no protection required for single CPU per policy case today, > and adding any kind of locking there, to supply remote callbacks, > isn't really a good idea. > > o If is local CPU isn't part of the same cpufreq policy as the target > CPU, then we wouldn't be able to do fast switching at all and have to > use some kind of bottom half to schedule work on the target CPU to do > real switching. That may be overkill as well. > > > And so this series only allows remote callbacks for target CPUs that > share the cpufreq policy with the local CPU. > > This series is tested with couple of usecases (Android: hackbench, > recentfling, galleryfling, vellamo, Ubuntu: hackbench) on ARM hikey > board (64 bit octa-core, single policy). Only galleryfling showed minor > improvements, while others didn't had much deviation. > > The reason being that this patchset only targets a corner case, where > following are required to be true to improve performance and that > doesn't happen too often with these tests: > > - Task is migrated to another CPU. > - The task has maximum demand initially, and should take the CPU to > higher OPPs. > - And the target CPU doesn't call into schedutil until the next tick. I don't have any problems with this series at this point, so you can add Acked-by: Rafael J. Wysocki to the patches. I can't apply them without ACKs from Peter or Ingo, though. Thanks, Rafael