On Wed, Jun 21, 2017 at 2:22 AM, Thomas Gleixner <[email protected]> wrote: > On Tue, 20 Jun 2017, Andy Lutomirski wrote: >> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c >> index 216d7ec88c0c..2ae43f59091d 100644 >> --- a/drivers/idle/intel_idle.c >> +++ b/drivers/idle/intel_idle.c >> @@ -912,16 +912,15 @@ static __cpuidle int intel_idle(struct cpuidle_device >> *dev, >> struct cpuidle_state *state = &drv->states[index]; >> unsigned long eax = flg2MWAIT(state->flags); >> unsigned int cstate; >> - int cpu = smp_processor_id(); >> >> cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1; >> >> /* >> - * leave_mm() to avoid costly and often unnecessary wakeups >> - * for flushing the user TLB's associated with the active mm. >> + * NB: if CPUIDLE_FLAG_TLB_FLUSHED is set, this idle transition >> + * will probably flush the TLB. It's not guaranteed to flush >> + * the TLB, though, so it's not clear that we can do anything >> + * useful with this knowledge. > > So my understanding here is: > > The C-state transition might flush the TLB, when cstate->flags has > CPUIDLE_FLAG_TLB_FLUSHED set. The idle transition already took the > CPU out of the set of CPUs which are remotely flushed, so the > knowledge about this potential flush is not useful for the kernels > view of the TLB state.
Indeed. I assume the theory behind the old code was that leave_mm() was expensive and that CPUIDLE_FLAG_TLB_FLUSHED would be a decent heuristic for when to do it.
