Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757084AbZFIQVc (ORCPT ); Tue, 9 Jun 2009 12:21:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754103AbZFIQVZ (ORCPT ); Tue, 9 Jun 2009 12:21:25 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49530 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753437AbZFIQVY (ORCPT ); Tue, 9 Jun 2009 12:21:24 -0400 Date: Tue, 9 Jun 2009 18:21:25 +0200 From: Nick Piggin To: Linus Torvalds Cc: Rusty Russell , Ingo Molnar , Jeremy Fitzhardinge , "H. Peter Anvin" , Thomas Gleixner , Linux Kernel Mailing List , Andrew Morton , Peter Zijlstra , Avi Kivity , Arjan van de Ven Subject: Re: [benchmark] 1% performance overhead of paravirt_ops on native kernels Message-ID: <20090609162125.GC9211@wotan.suse.de> References: <4A0B62F7.5030802@goop.org> <200906032208.28061.rusty@rustcorp.com.au> <200906041554.37102.rusty@rustcorp.com.au> <20090609093918.GC16940@wotan.suse.de> <20090609153847.GB9211@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1610 Lines: 37 On Tue, Jun 09, 2009 at 09:00:08AM -0700, Linus Torvalds wrote: > > > On Tue, 9 Jun 2009, Nick Piggin wrote: > > > > If it's such a problem, it could be made a lot faster without too > > much problem. You could just introduce a FIFO of ptes behind it > > and flush them all in one go. 4K worth of ptes per CPU might > > hopefully bring your overhead down to < 1%. > > We already have that. The regular kmap() does that. It's just not usable > in atomic context. Well this would be more like the kmap cache idea rather than the kmap_atomic FIFO (which would remain per-cpu and look much like the existing kmap_atomic). > We'd need to fix the locking: right now kmap_high() uses non-irq-safe > locks, and it does that whole cross-cpu flushing thing (which is why > those locks _have_ to be non-irq-safe. > > The way to fix that, though, would be to never do any cross-cpu calls, and > instead just have a cpumask saying "you need to flush before you do > anything with kmap". So you'd just set that cpumask inside the lock, and > if/when some other CPU does a kmap, they'd flush their local TLB at _that_ > point instead of having to have an IPI call. The idea seems nice but isn't the problem that kmap gives back a basically 1st class kernel virtual memory? (ie. it can then be used by any other CPU at any point without it having to use kmap?). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/