From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754510AbYHSHrR (ORCPT ); Tue, 19 Aug 2008 03:47:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752697AbYHSHrB (ORCPT ); Tue, 19 Aug 2008 03:47:01 -0400 Received: from one.firstfloor.org ([213.235.205.2]:46475 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752653AbYHSHrA (ORCPT ); Tue, 19 Aug 2008 03:47:00 -0400 Date: Tue, 19 Aug 2008 09:48:46 +0200 From: Andi Kleen To: Jeremy Fitzhardinge Cc: Andi Kleen , Ingo Molnar , LKML , x86@kernel.org, Nick Piggin , Jens Axboe Subject: Re: [PATCH 0 of 9] x86/smp function calls: convert x86 tlb flushes to use function calls [POST 2] Message-ID: <20080819074846.GE9807@one.firstfloor.org> References: <20080819004531.GI9914@elte.hu> <20080819073214.GD9807@one.firstfloor.org> <48AA79C4.8060309@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48AA79C4.8060309@goop.org> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Don't pay attention to that number. It's only the extra latency of a HT > context->HT context function call + tlb flush. Which means 1) the tlb > is shared anyway, so the extra flush is redundant, 2) they're not really > concurrent, 3) it's going down the single-cpu call, rather than the > multi-cpu one, 4) it's only measuring the latency for a particular tlb > flush, and doesn't take into account any throughput improvements the > extra queueing may add. A lot of flushes are synchronous. See the rest of my email that you snipped. -Andi