Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754817AbZFEEqf (ORCPT ); Fri, 5 Jun 2009 00:46:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752400AbZFEEqV (ORCPT ); Fri, 5 Jun 2009 00:46:21 -0400 Received: from ozlabs.org ([203.10.76.45]:35574 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754152AbZFEEqU (ORCPT ); Fri, 5 Jun 2009 00:46:20 -0400 From: Rusty Russell To: Linus Torvalds Subject: Re: [benchmark] 1% performance overhead of paravirt_ops on native kernels Date: Fri, 5 Jun 2009 14:16:18 +0930 User-Agent: KMail/1.11.2 (Linux/2.6.28-11-generic; KDE/4.2.2; i686; ; ) Cc: Ingo Molnar , Nick Piggin , Jeremy Fitzhardinge , "H. Peter Anvin" , Thomas Gleixner , Linux Kernel Mailing List , Andrew Morton , Peter Zijlstra , Avi Kivity , Arjan van de Ven References: <4A0B62F7.5030802@goop.org> <200906041554.37102.rusty@rustcorp.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906051416.19311.rusty@rustcorp.com.au> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1599 Lines: 37 On Fri, 5 Jun 2009 12:32:14 am Linus Torvalds wrote: > So I think your minimum and maximum configs should at least _match_ in > HIGHMEM. Limiting memory to not actually having any (with "mem=880M") will > avoid the TLB flushing impact of HIGHMEM, which is clearly going to be the > _bulk_ of the overhead, but HIGHMEM is still going to be noticeable on at > least some microbenchmarks. Well, Ingo was ranting because (paraphrase) "no other config option when *unused* has as much impact as CONFIG_PARAVIRT!!!!!!!!!!". That was the point of my mail; facts show it's simply untrue. > The comparison is ugly and pointless. (Re: SMP) Distributions don't ship UP kernels any more; this shows what that costs if you're actually on a UP box. If we really don't care, perhaps we should make CONFIG_SMP=n an option under EMBEDDED for x86. And we can rip out the complex patching SMP patching stuff too. > Something like CONFIG_HIGHMEM* or CONFIG_SMP is not really what I'd ever > call "optional feature", although I hope to Dog that CONFIG_HIGHMEM can > some day be considered that some day. Someone from a distro might know how many deployed machines don't need them. Kernel hackers tend to have modern machines; same with "enterprise" sites. I have no idea. Without those facts, I'll leave further discussion to someone else :) Thanks, Rusty. -- 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/