From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752887AbdFUQUf (ORCPT ); Wed, 21 Jun 2017 12:20:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:36278 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751133AbdFUPRU (ORCPT ); Wed, 21 Jun 2017 11:17:20 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0EEFC217C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: References: <2b3572123ab0d0fb9a9b82dc0deee8a33eeac51f.1498022414.git.luto@kernel.org> From: Andy Lutomirski Date: Wed, 21 Jun 2017 08:16:58 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 07/11] x86/mm: Stop calling leave_mm() in idle code To: Thomas Gleixner Cc: Andy Lutomirski , X86 ML , "linux-kernel@vger.kernel.org" , Borislav Petkov , Linus Torvalds , Andrew Morton , Mel Gorman , "linux-mm@kvack.org" , Nadav Amit , Rik van Riel , Dave Hansen , Arjan van de Ven , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 21, 2017 at 2:22 AM, Thomas Gleixner 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.