From patchwork Thu Jun 29 05:26:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 106603 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp703880qge; Wed, 28 Jun 2017 22:27:56 -0700 (PDT) X-Received: by 10.99.120.199 with SMTP id t190mr13845159pgc.176.1498714076590; Wed, 28 Jun 2017 22:27:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498714076; cv=none; d=google.com; s=arc-20160816; b=RT+PGqCd4Sr9YsFQv+kkYC+F0LFeEMiV8UqKclKBPth4vTIuJL5biFwqEPrUSI9qK/ zEiQjGsmihDm0wZZI8hzR64mgRVfjgjRPBdCPv102bi3a5r55AoFHcamyrWMo2M5/Ew6 syezlSVqzO/eG1Qma43INSlVy8jaXlCfXjTTaTxoduumcrkR1bOYfVm+r2ZlJw+gUaua q93hBEMsaUuZ6Vfsd40vjGh1vOkN2LuotKrqo7OgFd3sSiWNjSkmiAcVsCHsgUIyMV4X D3Ad+/NLEnY7kqbrteJWyoouTJxRn1hI9BUNHiegTtgMXnXbUxqWeDntDCj4kG4M9J23 87LQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=oGN2EY06+bh5aYtTmR8hTRIEIe2t50joNmFoVvOACVQ=; b=JyZMFZ9/QmRzd+1RhfbLv1goi996d2L2FOpY/d0xdRH1+DU0DaQI37sSK0wIyWXWY0 XSt8cYWACsBvUnRQDsOGCE2uh0RcMRWWYnV3V/hcJ4QAEfm9tIjXNUyfmaUWhhijdpUD tyNstQSE9ZODufOaJ935P9qm4vtx7vmc1vL3GG9TFy8xAkwTiLiKIbPY4Nkb9jRpU26e Y09jwBkXcs+JU1NqUZ3jXCoAO5YyWFScs72nFq4ZeIXkkD7jGhzSdpwwo+z6BTZkkFX1 M+F1pNa5V28XhRp9UJ9RY7OT11qe2bF2OXHZfTVSW4XHct4kx9huuw+7YVAMzehrn80p 1VBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=TZtPkTsx; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-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 87si2975389pfk.133.2017.06.28.22.27.56; Wed, 28 Jun 2017 22:27:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-pm-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.b=TZtPkTsx; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-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 S1751669AbdF2F1z (ORCPT + 14 others); Thu, 29 Jun 2017 01:27:55 -0400 Received: from mail-pg0-f49.google.com ([74.125.83.49]:32997 "EHLO mail-pg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751596AbdF2F1y (ORCPT ); Thu, 29 Jun 2017 01:27:54 -0400 Received: by mail-pg0-f49.google.com with SMTP id f127so42323456pgc.0 for ; Wed, 28 Jun 2017 22:27:54 -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; bh=oGN2EY06+bh5aYtTmR8hTRIEIe2t50joNmFoVvOACVQ=; b=TZtPkTsx4Ns978VT2kckiqtoKHdyrJqgbVVwBlRXl8DEJJpeGpx3fvL35wgr0vK9br 9Thg6kSKXO18DEZv6OFSedFznPbgKwqqmJ5zt5OnC6pPEYjq7VLaH2q7cN/s8qnhLrQC bQNWUDICn6fjbuA7x/8Gjig1stGz7A6DHuxnw= 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=oGN2EY06+bh5aYtTmR8hTRIEIe2t50joNmFoVvOACVQ=; b=YVti4smUbtxYq2nocJFLVMVqYQBun0Aovu/rFAiWLFC8HQAaQpfCve5oQYIoUsucay N/8adcUm/TmmsOmlSp/ZlCaP9vygmOK+cM0Kdc6oekfV0LEj6G36WperREqP7zbMYW6W nj4Rv5GsLeyi753o9FBCfEh9scPGtc1TmRHvDNKXuT7CWFhFWP+4DUQxHwW/kBlj3giQ YZqivbRqMtoPEZHp8IeJBJrCqfHyYAUA/ap9lMcXikVOMp/a2CLfKJxriyOMeBCj1ZDr UmY/sPOreWdrEi4J4qp1lCdXUcxjJr1SH0dJVcrVqGTioHCwn7nZdTqI+kiW2jA0GRAv AJ1A== X-Gm-Message-State: AKS2vOy121Y+O0+7zuYiGYgoxlpryA6F0z0NReK9yrt+XgkvgH2IIeaT NpqQub4cWM2RZmoW X-Received: by 10.98.207.2 with SMTP id b2mr10785814pfg.16.1498714073523; Wed, 28 Jun 2017 22:27:53 -0700 (PDT) Received: from localhost ([122.171.238.149]) by smtp.gmail.com with ESMTPSA id k73sm10060493pge.13.2017.06.28.22.27.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 22:27:52 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Ingo Molnar , Peter Zijlstra Cc: Viresh Kumar , linux-pm@vger.kernel.org, Vincent Guittot , linux-kernel@vger.kernel.org, smuckle.linux@gmail.com, juri.lelli@arm.com, Morten.Rasmussen@arm.com, patrick.bellasi@arm.com, eas-dev@lists.linaro.org Subject: [PATCH V2 0/4] sched: cpufreq: Allow remote callbacks Date: Thu, 29 Jun 2017 10:56:29 +0530 Message-Id: X-Mailer: git-send-email 2.13.0.71.gd7076ec9c9cb Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Hi, Here is the second version of this series. The first [1] version was sent several months back. 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 [2] 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. Taking above challenges into consideration, this version proposes a much simpler diff as compared to the first version. This series only allows remote callbacks for target CPUs that share the cpufreq policy with the local CPU. Locking is mostly in place everywhere and we wouldn't be required to change a lot of things. 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. V1->V2: - Don't support remote callbacks for unshared cpufreq policies. - Don't support remote callbacks where local CPU isn't part of the target CPU's cpufreq policy. - Dropped dvfs_possible_from_any_cpu flag. -- viresh [1] https://marc.info/?l=linux-pm&m=148906015927796&w=2 [2] http://pastebin.com/7LkMSRxE Steve Muckle (1): intel_pstate: Ignore scheduler cpufreq callbacks on remote CPUs Viresh Kumar (3): cpufreq: schedutil: Process remote callback for shared policies cpufreq: governor: Process remote callback for shared policies sched: cpufreq: Enable remote sched cpufreq callbacks drivers/cpufreq/cpufreq_governor.c | 4 ++++ drivers/cpufreq/intel_pstate.c | 3 +++ include/linux/sched/cpufreq.h | 1 + kernel/sched/cpufreq.c | 1 + kernel/sched/cpufreq_schedutil.c | 19 ++++++++++++++----- kernel/sched/deadline.c | 2 +- kernel/sched/fair.c | 8 +++++--- kernel/sched/rt.c | 2 +- kernel/sched/sched.h | 10 ++-------- 9 files changed, 32 insertions(+), 18 deletions(-) -- 2.13.0.71.gd7076ec9c9cb