Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp4543632rwb; Sun, 4 Dec 2022 04:08:33 -0800 (PST) X-Google-Smtp-Source: AA0mqf4rY8y1+RRPXp/7ctuc3qbPr6KAKKt4+W9yBUN4aezIhO0TXIIoFz4KqzpFkM6Q/OOYLkPe X-Received: by 2002:a17:90a:7e0d:b0:213:d630:f4af with SMTP id i13-20020a17090a7e0d00b00213d630f4afmr85259781pjl.77.1670155713728; Sun, 04 Dec 2022 04:08:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670155713; cv=none; d=google.com; s=arc-20160816; b=zYTpJLfRltb9vQPGU+4Yv3sXGqrdTBUPo4DEeYppL9lZF7snCjMdmTwXWvoJk749PF ah89weWT9loQ7FxxzzchO2Ru1H4IHXpVBlccud26Hi5gohR+AnxTodFsaupC5JkRxVBH uioIa2REMLVEG+m+fLgWJTOPUcYz6udPCJxeLVHKgiUoyfzc+frI6LdlyuEKUmYGrWtP 47ZQyso8MWHnjFDSG7LFHz/TZ38oCbtWXxGCGN0xo6SK/68HMYAjqSBSdOti2Kwaomhm 4fuWHiU/88d1PwiGhvRZ7XeXdNmGiXGm0O5PgiRQw3mfoShYqLjZezZ3bAGOqWAWgH9m 35tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=wCqCVlm2gWWxwc47amlLDLZQfBgu2mBenlFlBGkMsAs=; b=vmrYGg/HXcS7iXe6Bd2YkZHXcyJul2hl6pzPYtEr/BEZLiTYdRvsnX5A/3ypNAGMne XKQX1s6I0zaZ94VEWh0zS+DxSTtSGVrQWiUe/RscnityEgD2L2a/ljM2/B1hRgJTsUvT TbUi4IyipNZgs2vvL3/QNYtei9js3aprvSIT7o/sAE93eKKvG70vhbomF6Q22VqmnqnQ MQQaiew3pW8NNaugkkdhQCUeHLwuCIiB8d+2C2W8vbpeKIAM6WL5oaRvR7vxzXNPumdq vjweO8mkqHG896C45IezFEzAEhqU3rcKRhoxZRXWQYgVsDFGX37kN3PT+7l1E5Eulhly vaqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=peS3N8wn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q9-20020a056a00084900b005752db14951si12880673pfk.218.2022.12.04.04.08.22; Sun, 04 Dec 2022 04:08:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=peS3N8wn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S230010AbiLDLf4 (ORCPT + 82 others); Sun, 4 Dec 2022 06:35:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229800AbiLDLfv (ORCPT ); Sun, 4 Dec 2022 06:35:51 -0500 Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6558F027 for ; Sun, 4 Dec 2022 03:35:50 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id z9so3948169ilu.10 for ; Sun, 04 Dec 2022 03:35:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wCqCVlm2gWWxwc47amlLDLZQfBgu2mBenlFlBGkMsAs=; b=peS3N8wnkuNUsfo2yCWLAmkMZJYQBcfR6BcAAC7dYHwjsrPOuFdr+Y9c32SSb22aeH 4KD/hwNVucWb3JgqqFv+5GrqdTwDTs9OEhl/mehCCgqlLxyQl9oOnDpvITU99EkhxaOC mTWC/K/AXXOg/21DKwAQaxnYFZYuVReS1rUwcLFlZ++lRul7PYtWEGCCYaO3IwAQe2mr 6GYVMZm3mjLoaXvsPjP16AkO9a6KD5bIrb5DJHeyAcfcgTiNG7oRditafWmQId01/cv2 AFAYBUfAVG+tfMV7t8pbgbFhAm8J8XLNMk9kevCNHfQ8YRq/GYwiV13EHKpRnr79UfSI dGXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wCqCVlm2gWWxwc47amlLDLZQfBgu2mBenlFlBGkMsAs=; b=cCN+edeiJBJgwllcMtO/uXTD0UqPUI0bWsqjhqvKy238aBes6JGHDxWxGeTaGgf2RY BNcwlBRDxkpYqYMuIvthiyFa8ARPQlJ4J1JDrBflJteYKE7WW4Ci9ZhMxc5ZjSXGDuVj lxY7s5FZY4F5F3kty81IBh5l0tRYtcTylFitJ1/4y/IvbUJbvSt4a/J1TvCLheI8RnHC VE1I9COr6+Jj9ZV3cs/7kVZVv7V1saVNvV0E1bC9bM+8BQG05JgyuNkEJuagCNJcZs/A BDEf8zXgp97vvlIl283V4E/Z7LQG51eCBE03mjIqJ4dwO/01o4+1Q8kY4dIzJNO4Qloi wbEg== X-Gm-Message-State: ANoB5pn7RFgEXxj2941Q+HF5OIlAOvmB8DLkPlLtEvc45BEJKkX645As Tnd9FxfQLC8KjhX59+4MvrZR6Xqabe+0pXOukrxPHw== X-Received: by 2002:a92:7c0c:0:b0:302:efa3:6230 with SMTP id x12-20020a927c0c000000b00302efa36230mr21867381ilc.232.1670153750075; Sun, 04 Dec 2022 03:35:50 -0800 (PST) MIME-Version: 1.0 References: <20221127141742.1644023-1-qyousef@layalina.io> <20221127141742.1644023-4-qyousef@layalina.io> <20221203143323.w32boxa6asqvvdnp@airbuntu> In-Reply-To: <20221203143323.w32boxa6asqvvdnp@airbuntu> From: Vincent Guittot Date: Sun, 4 Dec 2022 12:35:39 +0100 Message-ID: Subject: Re: [RFC PATCH 3/3] sched/fair: Traverse cpufreq policies to detect capacity inversion To: Qais Yousef Cc: Ingo Molnar , Peter Zijlstra , Dietmar Eggemann , "Rafael J. Wysocki" , Viresh Kumar , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Lukasz Luba , Wei Wang , Xuewen Yan , Hank , Jonathan JMChen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 3 Dec 2022 at 15:33, Qais Yousef wrote: > > On 12/02/22 15:57, Vincent Guittot 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) { > > > > So you are looping all cpufreq policy (and before the perf domain) in > > the period load balance. That' really not something we should or want > > to do > > Why is it not acceptable in the period load balance but acceptable in the hot > wake up path in feec()? What's the difference? This patch loops on all cpufreq policy in sched softirq, how can this be sane ? and not only in eas mode but also in the default asymmetric performance one. This inverted detection doesn't look like the right way to fix your problem IMO. That being said, i agree that I haven't made any other proposal apart that I think that you should use a different rules for task and for overutilized and part of your problem comes from this. Then this make eas and util_fits_cpu even more Arm specific and I still hope to merge sched_asym_cpucapacity and asym_packing a some levels because they looks more and more similar but each side is trying to add some SoC specific policy Vincent > > > Thanks! > > -- > Qais Yousef