Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3106028imm; Thu, 17 May 2018 03:33:32 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrogXqszlzNjG5IAisEu1vKpeBYbth+lL+YCTAlomajFVaXXItYZSHmhCSU+j4jFK9i0Hxy X-Received: by 2002:a65:4b02:: with SMTP id r2-v6mr3642232pgq.82.1526553212239; Thu, 17 May 2018 03:33:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526553212; cv=none; d=google.com; s=arc-20160816; b=UTX5I/CEwJzwgGHerE3IasHbyeRk+1xgP4a7wLWjlsaV70R3jQz+Q4GvESvG3YrTwq d0mvDOEKE5iLMGcct0mIBcL757+++zbF/0Csr/WL78cwFnQfGAGBxXq++cADfA4ONUo1 YQo53qWfDN8uQzueyZwyuERl2LHZsGywmPEVR8erNoYVYayQHxMosPE/iYL+0rgTumh9 RjxTPty2dKg+cLHUVWNPqH4WRGQy1EQLeYbCJB1DGj3zLaQYD9mB7eB8NgICf/88KO4b FU08M8xYt4CEnhloLZJW0ZVpyL5+jRjdwx/67EMtWsY5ttr6bF2zcuFw2fw/8hiHWKmX 1zQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=+/lb2OeJ8dmV1Izr4EKkqIA9OxUDRJV/kAEyNLsWQj0=; b=TwioiKX1LquzKhHIl7xawZ6mNIS6nFoljb9ZVkxb7PyihCY1FH7TF7zWzeZOiXtM+t LPXbFP5rnfa/aunjp45QYnZTHGzA+/3jho6cdkgIM1Cv4fKFcTwMlpuACW5ipJWONXrg pJmEaOCEFBEoBn07zcrNTTFzPWuKZGUZZVrSwND8H1smhVhU+eWtRV8YAXKKuFZprJIb lhKMAJMuKM7MVhjbcy1BR48EYNoiDp2n+AhEU66/4h9PMJDbHp1iwyPdB7DP3/SezApU gZyeDhzBrrugvP4kanCtJTyfF+vhcA3vM5OZufCDnREePbHtrwLvuvOPR5zr8SyxeUeO Cyeg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x24-v6si4869193pfk.311.2018.05.17.03.33.17; Thu, 17 May 2018 03:33:32 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751804AbeEQKdG (ORCPT + 99 others); Thu, 17 May 2018 06:33:06 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:47383 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751274AbeEQKdE (ORCPT ); Thu, 17 May 2018 06:33:04 -0400 Received: from 79.184.254.241.ipv4.supernova.orange.pl (79.184.254.241) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83) id 7057b021e26d47af; Thu, 17 May 2018 12:33:02 +0200 From: "Rafael J. Wysocki" To: Viresh Kumar , Dietmar Eggemann Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , linux-pm@vger.kernel.org, Pavan Kondeti , "Rafael J . Wysocki" , Juri Lelli , Joel Fernandes , Patrick Bellasi , Quentin Perret Subject: Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily" Date: Thu, 17 May 2018 12:32:29 +0200 Message-ID: <2334592.UYLPsVHIHB@aspire.rjw.lan> In-Reply-To: <20180509045527.ylf2nwolsxxcsjkq@vireshk-i7> References: <20180508073340.13114-1-dietmar.eggemann@arm.com> <20180509045527.ylf2nwolsxxcsjkq@vireshk-i7> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, May 9, 2018 6:55:27 AM CEST Viresh Kumar wrote: > On 08-05-18, 08:33, Dietmar Eggemann wrote: > > This reverts commit e2cabe48c20efb174ce0c01190f8b9c5f3ea1d13. > > > > Lifting the restriction that the sugov kthread is bound to the > > policy->related_cpus for a system with a slow switching cpufreq driver, > > which is able to perform DVFS from any cpu (e.g. cpufreq-dt), is not > > only not beneficial it also harms Enery-Aware Scheduling (EAS) on > > systems with asymmetric cpu capacities (e.g. Arm big.LITTLE). > > > > The sugov kthread which does the update for the little cpus could > > potentially run on a big cpu. It could prevent that the big cluster goes > > into deeper idle states although all the tasks are running on the little > > cluster. > > > > Example: hikey960 w/ 4.16.0-rc6-+ > > Arm big.LITTLE with per-cluster DVFS > > > > root@h960:~# cat /proc/cpuinfo | grep "^CPU part" > > CPU part : 0xd03 (Cortex-A53, little cpu) > > CPU part : 0xd03 > > CPU part : 0xd03 > > CPU part : 0xd03 > > CPU part : 0xd09 (Cortex-A73, big cpu) > > CPU part : 0xd09 > > CPU part : 0xd09 > > CPU part : 0xd09 > > > > root@h960:/sys/devices/system/cpu/cpufreq# ls > > policy0 policy4 schedutil > > > > root@h960:/sys/devices/system/cpu/cpufreq# cat policy*/related_cpus > > 0 1 2 3 > > 4 5 6 7 > > > > (1) w/o the revert: > > > > root@h960:~# ps -eo pid,class,rtprio,pri,psr,comm | awk 'NR == 1 || > > /sugov/' > > PID CLS RTPRIO PRI PSR COMMAND > > 1489 #6 0 140 1 sugov:0 > > 1490 #6 0 140 0 sugov:4 > > > > The sugov kthread sugov:4 responsible for policy4 runs on cpu0. (In this > > case both sugov kthreads run on little cpus). > > > > cross policy (cluster) remote callback example: > > ... > > migration/1-14 [001] enqueue_task_fair: this_cpu=1 cpu_of(rq)=5 > > migration/1-14 [001] sugov_update_shared: this_cpu=1 sg_cpu->cpu=5 > > sg_cpu->sg_policy->policy->related_cpus=4-7 > > sugov:4-1490 [000] sugov_work: this_cpu=0 > > sg_cpu->sg_policy->policy->related_cpus=4-7 > > ... > > > > The remote callback (this_cpu=1, target_cpu=5) is executed on cpu=0. > > > > (2) w/ the revert: > > > > root@h960:~# ps -eo pid,class,rtprio,pri,psr,comm | awk 'NR == 1 || > > /sugov/' > > PID CLS RTPRIO PRI PSR COMMAND > > 1491 #6 0 140 2 sugov:0 > > 1492 #6 0 140 4 sugov:4 > > > > The sugov kthread sugov:4 responsible for policy4 runs on cpu4. > > > > cross policy (cluster) remote callback example: > > ... > > migration/1-14 [001] enqueue_task_fair: this_cpu=1 cpu_of(rq)=7 > > migration/1-14 [001] sugov_update_shared: this_cpu=1 sg_cpu->cpu=7 > > sg_cpu->sg_policy->policy->related_cpus=4-7 > > sugov:4-1492 [004] sugov_work: this_cpu=4 > > sg_cpu->sg_policy->policy->related_cpus=4-7 > > ... > > > > The remote callback (this_cpu=1, target_cpu=7) is executed on cpu=4. > > > > Now the sugov kthread executes again on the policy (cluster) for which > > the Operating Performance Point (OPP) should be changed. > > It avoids the problem that an otherwise idle policy (cluster) is running > > schedutil (the sugov kthread) for another one. > > > > Cc: Viresh Kumar > > Cc: Rafael J. Wysocki > > Cc: Peter Zijlstra > > Cc: Ingo Molnar > > Cc: Pavan Kondeti > > Cc: Juri Lelli > > Cc: Joel Fernandes > > Cc: Patrick Bellasi > > Cc: Quentin Perret > > Signed-off-by: Dietmar Eggemann > > --- > > kernel/sched/cpufreq_schedutil.c | 6 +----- > > 1 file changed, 1 insertion(+), 5 deletions(-) > > > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > > index d2c6083304b4..63014cff76a5 100644 > > --- a/kernel/sched/cpufreq_schedutil.c > > +++ b/kernel/sched/cpufreq_schedutil.c > > @@ -523,11 +523,7 @@ static int sugov_kthread_create(struct sugov_policy *sg_policy) > > } > > > > sg_policy->thread = thread; > > - > > - /* Kthread is bound to all CPUs by default */ > > - if (!policy->dvfs_possible_from_any_cpu) > > - kthread_bind_mask(thread, policy->related_cpus); > > - > > + kthread_bind_mask(thread, policy->related_cpus); > > init_irq_work(&sg_policy->irq_work, sugov_irq_work); > > mutex_init(&sg_policy->work_lock); > > > > Acked-by: Viresh Kumar Applied, thanks!