From patchwork Thu Jul 13 06:44:36 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 107549 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp1830567qge; Wed, 12 Jul 2017 23:45:08 -0700 (PDT) X-Received: by 10.99.185.5 with SMTP id z5mr7785248pge.231.1499928308010; Wed, 12 Jul 2017 23:45:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499928308; cv=none; d=google.com; s=arc-20160816; b=URoqu1UWzUVKtnvDaS5mq7YTHkEuEMn3hLn48xSSLR9glTyuF/EZMO+9uR/ffMCBWd ROWz3wRbaXrYizOm5OrzZegXx4/dErlweDSa7FZUOjSHkEI7eeL1gepOc/TAMewCzjwk EE0XSXFP1mnUDda+p3rq5yN3p3QTk9FURp5E5CdSDahkMoAVK3ty1QrUpzhE1iIq0HZI SnET8ftKLKlhcuCdu3sH68g1Csus0RdAqubne9W27YoKPdo677grpTATnvhv0Btbq3+M eI6wp2FFGpweHrA+FTHj7IgnRiDDKQDY7PNwMR1ycKcrD9nGTt1vz8IMb9bZDG4VzK/t yC4w== 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=2XRIpnn9r3xikZz96k87E7CMW+Sg1wnRKSbgFHNI5NA=; b=VMU2gfuakCLLub1gXpHNSgqPhWJ9k2IVdkegJbN2Ul1YJ8YmcgtgD9Yuf9t9wCMj7h JXFxss4+KYdC8gU/4Tih8Y4KRS2xhgM/FFZOqwd1wcK4aGkPcNzTI17jou/I+9/RnpUA 8AVnEVdjM4R3kMEhVScAL9GPGhMXhIKsBzrRFKNS4pO1+x/Na8Escf5DG0vkiSWJO3pE qOq5sQUC9DdWQwJdDwxFb7Gxps3hnluhNZrQ7KWzMViNz2k7QKqS/AuONiGtnuLckri1 z8t96Lp+sHExxdccKTeTPXpdXMzBIyVOwRVd5dNLHL5vkTOQezEL1UJ0NGxnKTM/sHZ7 ur/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=DHfmZ58h; 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 t141si3602830pgb.271.2017.07.12.23.45.07; Wed, 12 Jul 2017 23:45:07 -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.b=DHfmZ58h; 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 S1751197AbdGMGpG (ORCPT + 25 others); Thu, 13 Jul 2017 02:45:06 -0400 Received: from mail-pf0-f174.google.com ([209.85.192.174]:35452 "EHLO mail-pf0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751153AbdGMGpE (ORCPT ); Thu, 13 Jul 2017 02:45:04 -0400 Received: by mail-pf0-f174.google.com with SMTP id c73so24724415pfk.2 for ; Wed, 12 Jul 2017 23:45:04 -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=2XRIpnn9r3xikZz96k87E7CMW+Sg1wnRKSbgFHNI5NA=; b=DHfmZ58hS+e6b9o6rszqkYOel2YMO3PG9X8hJ4p5VDkLRPq0BytqMrdxQw9uhnwriR QcQixryOezbQJt2tNslHEz7xW2KTTO5bgkROqpvdlylu/OR1r2lVLC6OD3aQ0TtL92FP uvYLoxanReyujZJyh++Y4wVimD+EEV59AT+H8= 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=2XRIpnn9r3xikZz96k87E7CMW+Sg1wnRKSbgFHNI5NA=; b=LFNmEEUH4ljCj1Tz1I/OdL2cMMkNZGH4RAHbDM+sNtMFeU3cWzleVPJZf2VwGrnayS 7HezGii1Gq6rmULASdtlUzUb11Ab6vEn8xDk0DsOsClv7I7uQYiuKNfHvHGWlX4sgwFw IeFIia7Alg3uo/UJMXrk0L966Jvvye85TTAgDgKojz6FDwEtjUssHaejqLEaPpCibllh euWiRawevaugXJGb+hHRvHt4/87YrPfx4mEIiIPGgD7hJcEcXEFc3kiZd/EXeZOe/7Bk YNffg055oLDgcO60o4pRsnQhvonP1shAdFcS4tiwxZWQBq0I6kAjfa8GdC3hSk4zqTz1 pJOQ== X-Gm-Message-State: AIVw113WHsxie9NH4h0yAy0QIaFYmXbZorT80te370P4USB1YeJ+D0kE HhhKc4kJ1l72V0uc X-Received: by 10.99.0.138 with SMTP id 132mr7855964pga.30.1499928303750; Wed, 12 Jul 2017 23:45:03 -0700 (PDT) Received: from localhost ([122.171.81.230]) by smtp.gmail.com with ESMTPSA id w125sm8939338pfb.117.2017.07.12.23.45.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 23:45:02 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki Cc: Viresh Kumar , linux-pm@vger.kernel.org, Vincent Guittot , smuckle.linux@gmail.com, juri.lelli@arm.com, Morten.Rasmussen@arm.com, patrick.bellasi@arm.com, eas-dev@lists.linaro.org, Ingo Molnar , Len Brown , linux-kernel@vger.kernel.org, Peter Zijlstra , Srinivas Pandruvada Subject: [PATCH V3 0/3] sched: cpufreq: Allow remote callbacks Date: Thu, 13 Jul 2017 12:14:36 +0530 Message-Id: X-Mailer: git-send-email 2.13.0.71.gd7076ec9c9cb Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. V2->V3: - Rearranged/merged patches as suggested by Rafael (looks much better now) - Also handle new hook added to intel-pstate driver. - The final code remains the same as V2, except for the above hook. 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] http://pastebin.com/7LkMSRxE Viresh Kumar (3): sched: cpufreq: Allow remote cpufreq callbacks cpufreq: schedutil: Process remote callback for shared policies cpufreq: governor: Process remote callback for shared policies drivers/cpufreq/cpufreq_governor.c | 4 ++++ drivers/cpufreq/intel_pstate.c | 8 ++++++++ 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, 37 insertions(+), 18 deletions(-) -- 2.13.0.71.gd7076ec9c9cb Acked-by: Rafael J. Wysocki