Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752462AbcDFErp (ORCPT ); Wed, 6 Apr 2016 00:47:45 -0400 Received: from mail-oi0-f46.google.com ([209.85.218.46]:33428 "EHLO mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750705AbcDFEro (ORCPT ); Wed, 6 Apr 2016 00:47:44 -0400 MIME-Version: 1.0 In-Reply-To: <1459912457-5630-1-git-send-email-alex.shi@linaro.org> References: <1459912457-5630-1-git-send-email-alex.shi@linaro.org> From: Andy Lutomirski Date: Tue, 5 Apr 2016 21:47:23 -0700 Message-ID: Subject: Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT To: Alex Shi Cc: X86 ML , Thomas Gleixner , Ingo Molnar , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Andrew Morton , "H. Peter Anvin" , Rik van Riel 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: 594 Lines: 16 On Apr 5, 2016 8:17 PM, "Alex Shi" wrote: > > It seems Intel core still share the TLB pool, flush both of threads' TLB > just cause a extra useless IPI and a extra flush. The extra flush will > flush out TLB again which another thread just introduced. > That's double waste. Do you have a reference in both the SDM and the APM for this? Do we have a guarantee that this serialized the front end such that the non-targetted sibling won't execute an instruction that it decoded from a stale translation? This will conflict rather deeply with my PCID series, too. --Andy