On Wed, Jun 21, 2017 at 2:22 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
