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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86C87C352A1 for ; Sat, 3 Dec 2022 14:32:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229715AbiLCOcW (ORCPT ); Sat, 3 Dec 2022 09:32:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229448AbiLCOcV (ORCPT ); Sat, 3 Dec 2022 09:32:21 -0500 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F6ADDC5 for ; Sat, 3 Dec 2022 06:32:20 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id bx10so12174312wrb.0 for ; Sat, 03 Dec 2022 06:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8QjdvcBfpY62HjxgDg6d8xd9Ur3ryWmHVOJJHV4pl8o=; b=i+YT32mwJOa7srtTEon4jLCGGthL7khqDRCB8hLwQKxDeqrwVBVqNpIFtF2q9DQUT7 d+dTN8UhbnJrjIAP4DD4mHBadMnss56aJM+4KpRbtUvOsTjtNp573o7Lmf91gp6NG4Yw Nwqu5+eAKl2EbUBs3BbURkpcX9895p5zPUhAQFQyQa7+UOLh7mGk7b0NZ1c+TynzTGr0 Bpz+qNlkhJWABWkwYcmcYM7Dimau0tgVa08RLmDYe3AWrBFtWNoOYyoi+SQMk8a8X+Yc +JKh9NMjWiJRinJxfH8GMen1SHxdk8t2/BSboLJe5QCaFdQM/PUaL4kwHEIdFgNa92Tk eT5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8QjdvcBfpY62HjxgDg6d8xd9Ur3ryWmHVOJJHV4pl8o=; b=7Ta4kVWyPJb6dalNzI5OonnBbiY/KwBzlR9uf6uv68p9dAtKoLyfeMEwjAcrXfzeOO 9tOAk7WhmWyZnLLiMdarPNdshQGVKC95euFoEU58OuIxkuK4O0H518crmYg97XnCfsve hXzcKj+0yWeBTtzl3fjaDdUbhjEi40HkB3Cv6u9RazGDu/nLEHhDSwSmmCHCY7g0fHM1 MNLUtvBLt8TgICjxq1bDITk5Taf0GU0j0FQCYcTV9bJiL20JvFl1q2fuSvyQ908PGqTS wTSC056fk6UF8W1A3V3BoG0uutoBcU3RrWS4eHhkwn4ib2yPsSsUhhmxZ3SzUkfL2pr+ MOGA== X-Gm-Message-State: ANoB5pnpxMnGk/mMux5mkT9vB7ToQr5UwlXHdrDDw0ipVvmyshzcQQ/e 39uVL1F+Y/SHWSg7FG+7ZOVcig== X-Google-Smtp-Source: AA0mqf5NQRPKlfSryMZww1AyP9jTO5a0yDUixPctCLCktjrEFR4gnc6+jwzHMn5lW8pX3In+gvw0ag== X-Received: by 2002:adf:ba87:0:b0:241:c471:72b4 with SMTP id p7-20020adfba87000000b00241c47172b4mr37412701wrg.238.1670077938687; Sat, 03 Dec 2022 06:32:18 -0800 (PST) Received: from airbuntu (host86-130-134-87.range86-130.btcentralplus.com. [86.130.134.87]) by smtp.gmail.com with ESMTPSA id c14-20020a05600c0a4e00b003cffd3c3d6csm11668898wmq.12.2022.12.03.06.32.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 03 Dec 2022 06:32:18 -0800 (PST) Date: Sat, 3 Dec 2022 14:32:16 +0000 From: Qais Yousef To: "Rafael J. Wysocki" Cc: Ingo Molnar , Peter Zijlstra , Vincent Guittot , Dietmar Eggemann , Viresh Kumar , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Lukasz Luba , Wei Wang , Xuewen Yan , Hank , Jonathan JMChen Subject: Re: [RFC PATCH 3/3] sched/fair: Traverse cpufreq policies to detect capacity inversion Message-ID: <20221203143216.oezd2u6dpxodpuc3@airbuntu> References: <20221127141742.1644023-1-qyousef@layalina.io> <20221127141742.1644023-4-qyousef@layalina.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On 11/30/22 19:27, Rafael J. Wysocki wrote: > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 7c0dd57e562a..4bbbca85134b 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -8856,23 +8856,20 @@ static void update_cpu_capacity(struct sched_domain *sd, int cpu) > > * * Thermal pressure will impact all cpus in this perf domain > > * equally. > > */ > > - if (sched_energy_enabled()) { > > + if (static_branch_unlikely(&sched_asym_cpucapacity)) { > > unsigned long inv_cap = capacity_orig - thermal_load_avg(rq); > > - struct perf_domain *pd = rcu_dereference(rq->rd->pd); > > + struct cpufreq_policy *policy, __maybe_unused *policy_n; > > > > rq->cpu_capacity_inverted = 0; > > > > - SCHED_WARN_ON(!rcu_read_lock_held()); > > - > > - for (; pd; pd = pd->next) { > > - struct cpumask *pd_span = perf_domain_span(pd); > > + for_each_active_policy_safe(policy, policy_n) { > > 1. Is the "safe" part sufficient for protection against concurrent > deletion and freeing of list entries? cpufreq driver removal can do > that AFAICS. The freeing part is not safe probably. I need to research this more. Do you have issues against the exportation of this traversal in principle? Switching them to be RCU protected could be the best safe option, anything against that too? I might not end up needing that. I need to dig more. > 2. For a casual reader of this code it may not be clear why cpufreq > policies matter here. I'm looking for a way to traverse the list of capacities of the system and know their related CPUs. AFAICT this information already exists in the performance domains and cpufreq_policy. Performance domains are conditional to energy model and schedutil. So trying to switch to cpufreq_policy. Assuming this question wasn't a request to add a comment :-) Thanks! -- Qais Yousef