Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751076AbWH2QFo (ORCPT ); Tue, 29 Aug 2006 12:05:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751133AbWH2QFn (ORCPT ); Tue, 29 Aug 2006 12:05:43 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:9092 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S1751076AbWH2QFn (ORCPT ); Tue, 29 Aug 2006 12:05:43 -0400 Subject: Re: The 3G (or nG) Kernel Memory Space Offset From: Arjan van de Ven To: Dong Feng Cc: Jan Engelhardt , Andi Kleen , Nick Piggin , Paul Mackerras , Christoph Lameter , David Howells , linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Organization: Intel International BV Date: Tue, 29 Aug 2006 18:05:03 +0200 Message-Id: <1156867503.2722.72.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: 1256 Lines: 35 On Wed, 2006-08-30 at 00:01 +0800, Dong Feng wrote: > 2006/8/29, Jan Engelhardt : > > > > "0-4G physical memory space" denotes RAM. Since kernelspace is resident, it > > only seems logical to map it to 0G (that is, the start of RAM), because the > > end of RAM can be flexible. > > > > IOW, you cannot map kernelspace to the physical location 0xc0000000 because > > there might not be that much RAM. > > > > (Also note the PCI memory hole which is near the end of the 4G range.) > > > > > > Jan Engelhardt > > -- > > > > > Sorry for my typo. I actually means "0-1G physical memory space." My > question is actually why there is a 3G offset from linear kernel to > physical kernel. Why not simply have kernel memory linear space > located on 0-1G linear address, and therefore the physical kernel and > linear kernel just coincide? the price for that would be that you would have to flush all the tlb's on each syscall. That's seen as a quite hefty price by many kernel developers. - 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/