From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dave.hansen@intel.com>
X-Google-Smtp-Source: AH8x226Hxvk09AXeMBf2q6mmdc1aScszW2+PgF1pdShBmRDjnk5f879Oep1I8iA0o6kmafRw2rVf
ARC-Seal: i=1; a=rsa-sha256; t=1516909520; cv=none;
        d=google.com; s=arc-20160816;
        b=XSvw3sEJcJGD6REVCqIAtLYvFyFOCa5/8+8G3n31NvDE7twfNzQTu6lYsO7Gzmm4Zi
         NiP4IvB3fZzXq/OKay/igSwFHFQ3NyUU0VylnwxQvSkESwBHteT6bmnLchsSZKWb2/52
         7svWJ+vXamK8G5xEmWZNagRHx4/g86Pw+9wVhcWBMHfsLTHFYMHNwTQvsiKyIg4Sola3
         vQ01+HCfhBLecAjTSw9LUUCkeHyAABffGlYdF43RtCDKg8iD2XZ7f4EvM7QlZ43RGCJ9
         EhzyN2Rkoc8OuuSypYM5cfStd+CCTcdhKlWpz/qo0ACvSyaZN+JKqd7AoV6eChLfoRG5
         gHmw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:content-language:in-reply-to:mime-version
         :user-agent:date:message-id:from:cc:references:to:subject
         :arc-authentication-results;
        bh=f17nl83Xo506b+Rf80a55gzyXSNuzmRJAakbIYdIs7Y=;
        b=OX72euaEA01ArFSXLO4TLmfgvC3/HELnoeCYwkFZvrtnQUEdmHUi+lnl4039aPRS6S
         Z1+LT5+Qkb7E2OyzAjn5yIuzSvePJhHZj24w656D3niACP0Nvmbud96NAskRniuqRVsY
         ++4pTcgchKCe3hthS2l+skoSwH0vo2hrxqI+3I7oJ84Dif8+r0KP3ATeUnnkeWhahgYg
         6S2wfG7ItMMsCHDNPXMS9iVUDffN5UL2syJkxLlas3ZN6WOQ/VLCCOV+lA9kVkvgSYKo
         gyVUqLIcN+tONJtpp0fdILjRJvCCE0cQh05zvIvr1jCJAsU0wUUz+TFsMWwFPZEGKYr4
         KcgQ==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: domain of dave.hansen@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=dave.hansen@intel.com
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of dave.hansen@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=dave.hansen@intel.com
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.46,413,1511856000";
   d="scan'208";a="26364718"
Subject: Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same
 user process
To: Arjan van de Ven <arjan@linux.intel.com>,
 Tim Chen <tim.c.chen@linux.intel.com>, Peter Zijlstra
 <peterz@infradead.org>, Andy Lutomirski <luto@kernel.org>
References: <c5cc429013c2248ddebe0a8480b172ae70b29733.1516840211.git.tim.c.chen@linux.intel.com>
 <20180125085820.GV2228@hirez.programming.kicks-ass.net>
 <20180125092233.GE2295@hirez.programming.kicks-ass.net>
 <86541aca-8de7-163d-b620-083dddf29184@linux.intel.com>
 <20180125135055.GK2249@hirez.programming.kicks-ass.net>
 <aeef4a08-7dd3-3d3a-02f4-9b8b4a1461bf@linux.intel.com>
 <20180125164139.GM2269@hirez.programming.kicks-ass.net>
 <CALCETrVeb7g+wAP8hox9TEBBWYAFXGzOv5t2aQVrtuW4D6NQQQ@mail.gmail.com>
 <20180125181852.GL2249@hirez.programming.kicks-ass.net>
 <aa7cfe53-d8ee-9f56-a5c7-775d878cee15@linux.intel.com>
 <679180a8-cd7c-9200-224e-a93f0af77db7@linux.intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>, KarimAllah Ahmed
 <karahmed@amazon.de>, Andi Kleen <ak@linux.intel.com>,
 Andrea Arcangeli <aarcange@redhat.com>, Ashok Raj <ashok.raj@intel.com>,
 Asit Mallick <asit.k.mallick@intel.com>, Borislav Petkov <bp@suse.de>,
 Dan Williams <dan.j.williams@intel.com>, David Woodhouse
 <dwmw@amazon.co.uk>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "H . Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
 Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>,
 Joerg Roedel <joro@8bytes.org>, Jun Nakajima <jun.nakajima@intel.com>,
 Laura Abbott <labbott@redhat.com>,
 Linus Torvalds <torvalds@linux-foundation.org>,
 Masami Hiramatsu <mhiramat@kernel.org>, Paolo Bonzini <pbonzini@redhat.com>,
 Radim Krcmar <rkrcmar@redhat.com>, Thomas Gleixner <tglx@linutronix.de>,
 Tom Lendacky <thomas.lendacky@amd.com>, X86 ML <x86@kernel.org>
From: Dave Hansen <dave.hansen@intel.com>
Message-ID: <ab0e44f2-2f5a-8d11-e03f-a54cf930541f@intel.com>
Date: Thu, 25 Jan 2018 11:45:18 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <679180a8-cd7c-9200-224e-a93f0af77db7@linux.intel.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: =?utf-8?q?1590523944221221739?=
X-GMAIL-MSGID: =?utf-8?q?1590594917479262049?=
X-Mailing-List: linux-kernel@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>

On 01/25/2018 11:34 AM, Arjan van de Ven wrote:
>> This patch tries to address the case when we do switch to init_mm
>> and back. Do you still have objections to the approach in this
>> patch to save the last active mm before switching to init_mm?
> 
> how do you know the last active mm did not go away and started a new
> process with new content?
> (other than taking a reference which has other side effects)

We couldn't think of an easy way to prevent mm reuse other than taking a
reference.  Think of it this way: the mm getting run poisons a CPU.  We
can either go at exit() time and do IBPB on every CPU that might have
poison from the mm.  Or, we do IBPB once on each CPU the first time the
mm runs there to make sure that no old poison is still around.

Both of those require per-cpu state in the mm, kinda like the TLB
tracking.  That will not be fun to get right.  It also adds overhead to
the common-case exit() or fork() paths.  Also not fun.

The refcount just eats a little memory for the mm *itself* but none of
the actual expensive stuff: VMAs or page tables that hang off the mm.
It's also zero-cost at fork/exit.  The going-to-idle cost is manageable
and *certainly* outweighs the cost of even one extra IBPB that we would
otherwise have to do.