From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 861D8C43603 for ; Tue, 10 Dec 2019 11:03:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 626A92073B for ; Tue, 10 Dec 2019 11:03:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727227AbfLJLDY (ORCPT ); Tue, 10 Dec 2019 06:03:24 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:46664 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727114AbfLJLDY (ORCPT ); Tue, 10 Dec 2019 06:03:24 -0500 Received: from 79.184.255.117.ipv4.supernova.orange.pl (79.184.255.117) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.320) id 878d41276126c033; Tue, 10 Dec 2019 12:03:22 +0100 From: "Rafael J. Wysocki" To: Viresh Kumar Cc: Anson Huang , "Rafael J. Wysocki" , Peng Fan , Jacky Bai , "linux-pm@vger.kernel.org" , Vincent Guittot , Peter Zijlstra , Paul McKenney Subject: Re: About CPU hot-plug stress test failed in cpufreq driver Date: Tue, 10 Dec 2019 12:03:21 +0100 Message-ID: <7300000.zMGgbreFFD@kreacher> In-Reply-To: <20191210085744.ocdcpubkmac6mk3i@vireshk-i7> References: <40413247.HltoIgKm8r@kreacher> <20191210085744.ocdcpubkmac6mk3i@vireshk-i7> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Tuesday, December 10, 2019 9:57:44 AM CET Viresh Kumar wrote: > On 10-12-19, 09:50, Rafael J. Wysocki wrote: > > Index: linux-pm/include/linux/cpufreq.h > > =================================================================== > > --- linux-pm.orig/include/linux/cpufreq.h > > +++ linux-pm/include/linux/cpufreq.h > > @@ -599,11 +599,13 @@ static inline bool cpufreq_this_cpu_can_ > > { > > /* > > * Allow remote callbacks if: > > - * - dvfs_possible_from_any_cpu flag is set > > * - the local and remote CPUs share cpufreq policy > > + * - dvfs_possible_from_any_cpu flag is set and the CPU running the > > + * code is not going offline. > > */ > > - return policy->dvfs_possible_from_any_cpu || > > - cpumask_test_cpu(smp_processor_id(), policy->cpus); > > + return cpumask_test_cpu(smp_processor_id(), policy->cpus) || > > + (policy->dvfs_possible_from_any_cpu && > > + !cpumask_test_cpu(smp_processor_id(), policy->related_cpus)); > > This isn't enough as you are assuming that only a CPU from policy->related_cpus > can do remote processing. On a ARM platform (like Qcom's Krait, octa-core), all > 8 CPUs have separate policies as they don't share clock lines. Though they can > still do remote processing for each other as the clk registers are common. > > Also policy->related_cpus can anyway update frequency for the policy even if > dvfs_possible_from_any_cpu is set to false. I know, see https://lore.kernel.org/linux-pm/CAJZ5v0h0934-VBODZZJ8gEG2byuhQ+bomoCuTmmQZOBtqu5bKQ@mail.gmail.com/T/#mccadfdc557468072ab6c5525601a71d60070e99b