Re: [PATCH 1/3] x86/mwait: Add support for idle via umwait

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Mar 07, 2023 at 12:55:45PM +0100, Rafael J. Wysocki wrote:
> On Mon, Mar 6, 2023 at 3:56 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Mon, Mar 06, 2023 at 02:34:16PM +0200, Artem Bityutskiy wrote:
> > > From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> > >
> > > On Intel platforms, C-states are requested using the 'monitor/mwait'
> > > instructions pair, as implemented in 'mwait_idle_with_hints()'. This
> > > mechanism allows for entering C1 and deeper C-states.
> > >
> > > Sapphire Rapids Xeon supports new idle states - C0.1 and C0.2 (later C0.x).
> > > These idle states have lower latency comparing to C1, and can be requested
> > > with either 'tpause' and 'umwait' instructions.
> > >
> > > Linux already uses the 'tpause' instruction in delay functions like
> > > 'udelay()'. This patch adds 'umwait' and 'umonitor' instructions support.
> > >
> > > 'umwait' and 'tpause' instructions are very similar - both send the CPU to
> > > C0.x and have the same break out rules. But unlike 'tpause', 'umwait' works
> > > together with 'umonitor' and exits the C0.x when the monitored memory
> > > address is modified (similar idea as with 'monitor/mwait').
> > >
> > > This patch implements the 'umwait_idle()' function, which works very
> > > similarly to existing 'mwait_idle_with_hints()', but requests C0.x. The
> > > intention is to use it from the 'intel_idle' driver.
> >
> > Still wondering wth regular mwait can't access these new idle states.
> 
> But is this a question for Artem to answer?

Maybe, maybe not, but I did want to call out this 'design' in public. It
is really weird IMO.