Re: [RFC PATCH 2/4] x86, mwaitt: introduce mwaitx idle with a configurable timer

[Ingo Molnar]

* Borislav Petkov <bp@xxxxxxx> wrote:

> On Wed, May 20, 2015 at 12:22:58PM +0200, Ingo Molnar wrote:
>
> > Well, HLT does not get any hint from the OS how long the idling is 
> > expected to last.
> 
> MWAIT on AMD doesn't either:

Yeah, MWAIT clearly doesn't, but I was talking about MWAITX, which 
takes a timeout parameter as per these patches.

> > Another MWAITX round - we've got no crystal ball, so the hint 
> > might be wrong if an external event occurs that we did not 
> > anticipate.
> 
> So if we end up doing a bunch of MWAITX rounds instead of HLT and 
> MWAITX saves less power than HLT, then we practically are worse.

So the way I think it would work ideally is (and note that this is 
different from how you think it works):

  - MWAITX takes a 'timeout' parameter, but otherwise behaves exactly 
    like MWAIT: i.e. once idle it won't exit idle on its own

  - based on the 'timeout' hint, MWAITX can internally optimize how 
    deep sleep it enters. If the timeout is large it goes deep, if 
    it's small, it goes shallow. This does not change the fact that no 
    matter which state it enters, it will come back the moment an 
    interrupt is posted.

if actual behavior departs from this ideal behavior then we need to 
know.

> > I don't think MWAITX will wake up in itself. (If yes then it's 
> > essentially a timer in disguise and needs a whole different 
> > approach!)
> 
> I mean when the MWAITX timeout expires. When it does, we wake up.

I'm not sure that's the case, see above what I think would be the 
ideal behavior.

If it's a true timeout, as you suggest, then I don't see any obvious 
way to support it, especially if it does not give access to deeper 
sleep states.

> Also, normal MWAIT allows for interrupts to wake it up:

of course! That's a necessary feature as otherwise we could stay stuck 
indefinitely.

This MWAIT extension:

> "ECX specifies optional extensions for the MWAIT instruction. The 
> only extension currently defined is ECX bit 0, which allows 
> interrupts to wake MWAIT, even when eFLAGS.IF = 0. Support for this 
> extension is indicated by a feature flage returned by the CPUID 
> instruction."

is used by the Intel idle driver so that we can call MWAIT with 
interrupts disabled - but it behaves as if interrupts were enabled.

> > The question would be: on systems that provide ACPI idle but also 
> > have MWAITX support, which one behaves better on the hardware 
> > side?
> 
> I'd venture a guess here that the ACPI side should be using all 
> C-states available (think of other OSes and having optimal power 
> savings there) and MWAITX would be worse or the same. Right now it 
> is entering some funny state between C0 and C1 reportedly:
> 
> "But on AMD platform, mwaitx/mwait cannot go to C1 or C1E like 
> intel. The power consumption of waiting phase is somewhere in 
> between (C0 and C1). Actually, it's still in C0 but less power 
> consumption than normal C0."
> 
> So my thinking currently is - provided we want to use it at all:
> 
> * Use MWAITX on entry to idle, considering that on a busy system, 
> the statistical probability of this sleep timeout to be small, is 
> high.
> 
> * When the timeout expires and we wake up and realize there's still 
> nothing to do, we do HLT.
> 
> But all that is pointless if we end up in acpi_idle anyway...

Yeah.

Thanks,

	Ingo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/