[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0io8+zHwE82Z2z-GiTKwT63aHhbzDUhmZYHF3VwzbNaFw@mail.gmail.com>
Date: Wed, 27 Nov 2024 11:53:41 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Patryk Wlazlyn <patryk.wlazlyn@...ux.intel.com>
Cc: "Gautham R. Shenoy" <gautham.shenoy@....com>, x86@...nel.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, rafael.j.wysocki@...el.com, peterz@...radead.org,
dave.hansen@...ux.intel.com, tglx@...utronix.de, len.brown@...el.com,
artem.bityutskiy@...ux.intel.com
Subject: Re: [PATCH v5 1/3] x86/smp: Allow calling mwait_play_dead with an
arbitrary hint
On Wed, Nov 27, 2024 at 9:33 AM Patryk Wlazlyn
<patryk.wlazlyn@...ux.intel.com> wrote:
>
> > Hello Patryk,
> >
> > Apologies for what may appear as bikeshedding, after this patch, the
> > cpuidle code still won't call any mwait based play dead loop since the
> > support for enter_dead for FFh based idle states in acpi_idle and
> > intel_idle only gets added in Patches 2 and 3.
> >
> > Does it make sense to split this Patch 1 into 2 patches : 1/4 and 4/4
> >
> > 1/4 just introduces the mwait_play_dead_with_hint() helper which will
> > be used by patches 2 and 3.
> >
> > 4/4 get rids of the of logic to find the deepest state from
> > mwait_play_dead() and modifies native_play_dead() to call
> > cpuidle_play_dead() followed by hlt_play_dead() thus removing any
> > reference to mwait_play_dead(). Optionally you can even rename
> > mwait_play_dead_with_hints() to mwait_play_dead().
> >
> > That way the changelog that you have for this patch can be used in 4/4
> > since with the addition of play_dead support for FFh states in both
> > acpi_idle and intel_idle via patches 2 and 3, the logic to find the
> > deepest ffh state in mwait_play_dead() is no longer required.
> >
> > Thoughts ?
>
> Yeah, makes sense. I just wanted to simplify, but at some point crossed my mind
> that submitting it like you suggested may be better.
Not just it may be better, but this is the only way to do it or people
who apply the first patch without the other two patches will likely
have problems (and that may easily happen during bisection, for
example).
Things should always work between consecutive patches in a patch series.
> I am going to split that if I don't see any objections.
Yes, please!
Powered by blists - more mailing lists