Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751215AbWHHCtO (ORCPT ); Mon, 7 Aug 2006 22:49:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751216AbWHHCtO (ORCPT ); Mon, 7 Aug 2006 22:49:14 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:37079 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S1751215AbWHHCtN (ORCPT ); Mon, 7 Aug 2006 22:49:13 -0400 Subject: Re: [PATCH] x86_64: Make NR_IRQS configurable in Kconfig From: Arjan van de Ven To: Andrew Morton Cc: Andi Kleen , "Eric W. Biederman" , "Randy.Dunlap" , "Protasevich, Natalie" , linux-kernel@vger.kernel.org In-Reply-To: <20060807194159.f7c741b5.akpm@osdl.org> References: <20060807165512.dabefb63.akpm@osdl.org> <200608080417.59462.ak@suse.de> <20060807194159.f7c741b5.akpm@osdl.org> Content-Type: text/plain Organization: Intel International BV Date: Tue, 08 Aug 2006 04:47:49 +0200 Message-Id: <1155005284.3042.11.camel@laptopd505.fenrus.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1672 Lines: 42 On Mon, 2006-08-07 at 19:41 -0700, Andrew Morton wrote: > On Tue, 8 Aug 2006 04:17:59 +0200 > Andi Kleen wrote: > > > > > > > > > And it's a pretty nasty one because it can get people into the situation > > > where the kernel worked fine for those who released it, but users who > > > happen to load more modules (or the right combination of them) will > > > experience per-cpu memory exhaustion. > > > > Yes, and a high value will waste a lot of memory for normal users. > > > > > So shouldn't we being scaling the per-cpu memory as well? > > > > If we move it into vmalloc space it would be easy to extend at runtime - just the > > virtual address space would need to be prereserved, but then more pages > > could be mapped. Maybe we should just do that instead of continuing to kludge around? > > Sounds sane. > > otoh, we need something for 2.6.19. > > > Drawback would be some more TLB misses. > > yup. On some (important) architectures - I'm not sure which architectures > do the bigpage-for-kernel trick. also most of the architectures that do bigpage-for-kernel stuff only have a very limited number of tlb entries for bigpages (usually 2 to 4) while they have many more entries for normal pages.. so it's not automatically worse (now if these data structures are close to the kernel text or so.. then yes there's sharing. but with the sorting of kernel text that's a lot less true already) - 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/