Messages in this thread | | | Date | Wed, 20 May 2015 16:51:22 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC PATCH 2/4] x86, mwaitt: introduce mwaitx idle with a configurable timer |
| |
* Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 20 May 2015, Ingo Molnar wrote: > > * Borislav Petkov <bp@suse.de> wrote: > > > > > On Wed, May 20, 2015 at 01:11:20PM +0200, Ingo Molnar wrote: > > > > - MWAITX takes a 'timeout' parameter, but otherwise behaves exactly > > > > like MWAIT: i.e. once idle it won't exit idle on its own > > > > > > Let me quote the commit message: > > > > > > "MWAITT, another name is MWAITX (MWAIT with extensions), has a > > > configurable timer that causes MWAITX to exit on expiration." > > > > Ah. A useful skill that is, being able to read. > > > > > You need to set the second bit in ECX to enable the timer. > > > > > > I guess if you don't, then you get normal MWAIT but then you don't > > > need the timeout either... > > > > Yeah. > > > > So if it's a true timeout then we could use it to implement > > irq-less timers: that's actually pretty useful, because it could > > be faster than getting a local APIC timer irq, etc. > > Uurgh, NO NO NO!
I know, I know :-)
The XP PIC was a nasty, broken hardware timer, and all x86 timer generations after that made the situation even worse.
> We have enough trouble with non functional timers already, we do not > need another variant of those. > > We can supply the estimated sleep time though if that helps the PM > controller underneath to select a state. That's more or less what we > do in the governors as well.
That's not what appears to be happening here though: the MWAITX will return after the timeout.
Which isn't really useful unless we use it to drive timers.
So 'lets not use it' might be the sane answer.
Thanks,
Ingo
| |