From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757551AbcH2PBl (ORCPT ); Mon, 29 Aug 2016 11:01:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45296 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757417AbcH2PBk (ORCPT ); Mon, 29 Aug 2016 11:01:40 -0400 Message-ID: <1472482462.32433.92.camel@redhat.com> Subject: Re: [PATCH RFC UGLY] x86,mm,sched: make lazy TLB mode even lazier From: Rik van Riel To: Andy Lutomirski Cc: "H. Peter Anvin" , Mel Gorman , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Peter Zijlstra , Benjamin Serebrin , Ingo Molnar , Borislav Petkov Date: Mon, 29 Aug 2016 10:54:22 -0400 In-Reply-To: References: <20160825150515.02c2d8ea@riellap.home.surriel.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-C0PpiHLF4h5jdHKXNJZU" Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 29 Aug 2016 14:54:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-C0PpiHLF4h5jdHKXNJZU Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2016-08-28 at 01:11 -0700, Andy Lutomirski wrote: > On Aug 25, 2016 9:06 PM, "Rik van Riel" wrote: > >=20 > > Subject: x86,mm,sched: make lazy TLB mode even lazier > >=20 > > Lazy TLB mode can result in an idle CPU being woken up for a TLB > > flush, when all it really needed to do was flush %cr3 before the > > next context switch. > >=20 > > This is mostly fine on bare metal, though sub-optimal from a power > > saving point of view, and deeper C states could make TLB flushes > > take a little longer than desired. > >=20 > > On virtual machines, the pain can be much worse, especially if a > > currently non-running VCPU is woken up for a TLB invalidation > > IPI, on a CPU that is busy running another task. It could take > > a while before that IPI is handled, leading to performance issues. > >=20 > > This patch is still ugly, and the sched.h include needs to be > > cleaned > > up a lot (how would the scheduler people like to see the context > > switch > > blocking abstracted?) > >=20 > > This patch deals with the issue by introducing a third tlb state, > > TLBSTATE_FLUSH, which causes %cr3 to be flushed at the next > > context switch. A CPU is transitioned from TLBSTATE_LAZY to > > TLBSTATE_FLUSH with the rq lock held, to prevent context switches. > >=20 > > Nothing is done for a CPU that is already in TLBSTATE_FLUH mode. > >=20 > > This patch is totally untested, because I am at a conference right > > now, and Benjamin has the test case :) > >=20 >=20 > I haven't had a chance to seriously read the code yet, but what > happens when the mm is deleted outright?=C2=A0=C2=A0Or is the idea that a > reference is held until all the lazy users are gone, too? Worst case we send a TLB flush to a CPU that does not need it. As not sending an IPI will be faster than sending one, I do not think the tradeoff will be much different for a system with PCID. --=20 All Rights Reversed. --=-C0PpiHLF4h5jdHKXNJZU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXxEyeAAoJEM553pKExN6DJAcH/30WUDmySq0lw6SoibQP9iEx X3HDKSTmZIRuRE548FsQr2aMT2JUeDGzrUyZGmGiVY4fgqkDRWjDT6qlhj+2tjIW J3kx5NXSZxsNkmZfJo41J7B8tSNvJprMuL7I65H9OQuyTzMFjOZbmowCCYc0L9Ni Z3WQgLL45g8dQ+EEOWmy+mjlI50P5rG7J1gYgTw9UUbippNk3fB1JjCZJ1klc+Hh KmA8qwM2ygAIxaMKxgT7gm+kgNTgK6OrxdJl5T041C+/jepQZ+UwPTTmxGiBQnw6 6x9hUfxEdnwpWDcNiLMG7ImZViTL0Sm2yogKuU4fnNyhRcQBN8lxh45XTHyttoM= =5l/y -----END PGP SIGNATURE----- --=-C0PpiHLF4h5jdHKXNJZU--