Messages in this thread | | | Date | Wed, 20 May 2015 12:22:58 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC PATCH 2/4] x86, mwaitt: introduce mwaitx idle with a configurable timer |
| |
* Borislav Petkov <bp@suse.de> wrote:
> On Wed, May 20, 2015 at 10:55:20AM +0200, Ingo Molnar wrote: > > Does it use it to decide how 'deep' a sleep it will go into, i.e. > > larger timeouts cause longer entry and exit latencies? > > That's what the HLT thing does. Cores go into C1 and then at some > point (hysteresis, etc) the whole core complex enters C1E.
Well, HLT does not get any hint from the OS how long the idling is expected to last.
So I don't think it's the same thing.
> The MWAIT* should be used for only shorter sleeps as it remains in > C1. IMHO, of course. > > But the problem there is another: what happens if the timeout fires, > you wake up and see that you can remain idle? Do HLT? Do another > MWAITX round?
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.
As long as it's a statistical optimization it's OK: i.e. if the hardware only uses the timeout to determine how deep to sleep.
> This means you have an additional unnecessary wakeup which costs.
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 suppose it's also the case that if an interrupt arrives _before_ > > the expected timeout then MWAITX will try to exit immediately, it > > won't wait until the timeout, right? > > I'd assume so - I mean, it must, right. > > BUT!, in talking to Andy about it last night on IRC, he pointed out > that when using acpi_idle, we never come to calling x86_idle() and > from looking quickly at cpuidle_idle_call(), that still might be the > case as we go to use_default only when there's an error with the > cpuidle driver or so.
Yes, we don't normally see these idle handlers, ACPI takes over on most systems.
> So Rui, before you go and do more work on it, you should probably > analyze what cpuidle exactly does (if you haven't done so yet). And > on AMD we do use acpi_idle - at least on my F15h box that is the > case: > > $ grep . /sys/devices/system/cpu/cpuidle/current_* > /sys/devices/system/cpu/cpuidle/current_driver:acpi_idle > /sys/devices/system/cpu/cpuidle/current_governor_ro:menu
Yes.
The question would be: on systems that provide ACPI idle but also have MWAITX support, which one behaves better on the hardware side?
Thanks,
Ingo
| |