On 03/07/2025 2:30 pm, Jan Beulich wrote:
> On 03.07.2025 14:37, Andrew Cooper wrote:
>> On 03/07/2025 10:24 am, Jan Beulich wrote:
>>> On 02.07.2025 16:41, Andrew Cooper wrote:
>>>> With the recent simplifications, it becomes obvious that smp_mb() isn't the
>>>> right barrier; all we need is a compiler barrier.
>>>>
>>>> Include this in monitor() itself, along with an explantion.
>>> Ah, here we go. As per my comment on patch 4, would this perhaps better move
>>> ahead (which however would require a bit of an adjustment to the
>>> description)?
>> As said, it's not necessary in practice.
> As said where? All you say here is that a memory barrier is needed. Perhaps
> my use of "ahead" was ambiguous? I meant "move ahead in the series", not
> "move ahead in code". Apart from this as a possibility I fear I don't
> understand.
I did take it to mean "ahead in the series".
Your comment in patch 4 talks about alternative(), alternative_io() and
barriers. I stated (admittedly without reference) that the barrier
between two alternatives() doesn't matter because of their volatileness.
It can move in the series, because it is genuinely independent and
unrelated to patch 4 AFAICT.
>> Nothing good can come of having any loads hoisted above MWAIT, but from
>> a programmers point of view, it's indistinguishable from e.g. taking an
>> SMI. If there's a correctness issue, it's not MWAIT's fault.
> Well, yes, but what in the code is it that tells the compiler not to? Up
> to and including LTO, should we ever get that to work again. This
> specifically may be why mwait() may need to gain one, despite not itself
> dealing with any memory (operands).
In practice, mwait() is surrounded by spec_ctrl_{enter,exit}_idle() and
nothing is crossing those. I'm going to leave the mwait side of things
alone for now.
But even with LTO, if hoisting a read causes a problem, that's a bug in
whatever got hoisted, not in MWAIT.
~Andrew
