Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751058AbdFSEoS (ORCPT ); Mon, 19 Jun 2017 00:44:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:50368 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750790AbdFSEoR (ORCPT ); Mon, 19 Jun 2017 00:44:17 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4FC9C239F2 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: <20170618212948.mt33zbajt5n6saed@sasha-lappy> References: <20170618212948.mt33zbajt5n6saed@sasha-lappy> From: Andy Lutomirski Date: Sun, 18 Jun 2017 21:43:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 00/10] PCID and improved laziness To: "Levin, Alexander (Sasha Levin)" Cc: Andy Lutomirski , "x86@kernel.org" , "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 Content-Length: 1978 Lines: 45 On Sun, Jun 18, 2017 at 2:29 PM, Levin, Alexander (Sasha Levin) wrote: > On Tue, Jun 13, 2017 at 09:56:18PM -0700, Andy Lutomirski wrote: >>There are three performance benefits here: >> >>1. TLB flushing is slow. (I.e. the flush itself takes a while.) >> This avoids many of them when switching tasks by using PCID. In >> a stupid little benchmark I did, it saves about 100ns on my laptop >> per context switch. I'll try to improve that benchmark. >> >>2. Mms that have been used recently on a given CPU might get to keep >> their TLB entries alive across process switches with this patch >> set. TLB fills are pretty fast on modern CPUs, but they're even >> faster when they don't happen. >> >>3. Lazy TLB is way better. We used to do two stupid things when we >> ran kernel threads: we'd send IPIs to flush user contexts on their >> CPUs and then we'd write to CR3 for no particular reason as an excuse >> to stop further IPIs. With this patch, we do neither. >> >>This will, in general, perform suboptimally if paravirt TLB flushing >>is in use (currently just Xen, I think, but Hyper-V is in the works). >>The code is structured so we could fix it in one of two ways: we >>could take a spinlock when touching the percpu state so we can update >>it remotely after a paravirt flush, or we could be more careful about >>our exactly how we access the state and use cmpxchg16b to do atomic >>remote updates. (On SMP systems without cmpxchg16b, we'd just skip >>the optimization entirely.) > > Hey Andy, > > I've started seeing the following in -next: > > ------------[ cut here ]------------ > kernel BUG at arch/x86/mm/tlb.c:47! ... > Call Trace: > flush_tlb_func_local arch/x86/mm/tlb.c:239 [inline] > flush_tlb_mm_range+0x26d/0x370 arch/x86/mm/tlb.c:317 > flush_tlb_page arch/x86/include/asm/tlbflush.h:253 [inline] I think I see what's going on, and it should be fixed in the PCID series. I'll split out the fix.