Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 25 Sep 2020 14:59:00 +0100
From:   Quentin Perret <qperret@google.com>
To:     Ionela Voinescu <ionela.voinescu@arm.com>
Cc:     mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org,
        catalin.marinas@arm.com, will@kernel.org, rjw@rjwysocki.net,
        viresh.kumar@linaro.org, dietmar.eggemann@arm.com,
        valentin.schneider@arm.com, linux-pm@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] arm64: rebuild sched domains on invariance status
 changes
Message-ID: <20200925135900.GA11648@google.com>
References: <20200924123937.20938-1-ionela.voinescu@arm.com>
 <20200924123937.20938-4-ionela.voinescu@arm.com>
 <20200924133925.GC3920949@google.com>
 <20200924161002.GC17927@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200924161002.GC17927@arm.com>
Precedence: bulk

Hey Ionela,

On Thursday 24 Sep 2020 at 17:10:02 (+0100), Ionela Voinescu wrote:
> I'm not sure what is a good way of fixing this.. I could add more info
> to the warning to suggest it might be temporary ("Disabling EAS:
> frequency-invariant load tracking currently not supported"). For further
> debugging there are the additional prints guarded by sched_debug().
> 
> I'll look over the code some more to see if other ideas pop out. Any
> suggestions are appreciated.

Right, I'm not seeing anything perfect here, but I think I'd be
personally happy with this message being entirely guarded by
sched_debug(), like we do for asym CPU capacities for instance.

It's not easy to see if EAS has started at all w/o sched debug anyway,
so I expect folks who need it to enable the debug stuff during
bring-up. With a descriptive enough warn message, that should be just
fine. But that's my 2p, so I'm happy to hear if others disagree.

Thanks,
Quentin