From owner-freebsd-arch@FreeBSD.ORG Sat Jan 21 00:39:11 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED3DE16A41F; Sat, 21 Jan 2006 00:39:10 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BDDE43D48; Sat, 21 Jan 2006 00:39:10 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id 766DB4AB9D; Fri, 20 Jan 2006 18:39:09 -0600 (CST) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 24905-01-87; Fri, 20 Jan 2006 18:39:08 -0600 (CST) Received: by cs.rice.edu (Postfix, from userid 19572) id CE0EC4AAA5; Fri, 20 Jan 2006 18:39:08 -0600 (CST) Date: Fri, 20 Jan 2006 18:39:08 -0600 From: Alan Cox To: Poul-Henning Kamp Message-ID: <20060121003908.GD6017@cs.rice.edu> References: <43CD612E.2060002@elischer.org> <63333.1137536336@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63333.1137536336@critter.freebsd.dk> User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-2.2.1 at cs.rice.edu Cc: alc@freebsd.org, Julian Elischer , arch@freebsd.org Subject: Re: Large virtual page size support. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2006 00:39:11 -0000 On Tue, Jan 17, 2006 at 11:18:56PM +0100, Poul-Henning Kamp wrote: > In message <43CD612E.2060002@elischer.org>, Julian Elischer writes: > >Jeff Roberson wrote: > > > >> I have implemented support in the vm for PAGE_SIZE values which are a > >> multiple of the hardware page size. This is primarily useful for two > >> things: > > > >Mach (and the VM system we inherrited from it) had this. I beieve it was > >removed with teh comment > >"If we need this and someone is willing to support it it can be added > >back" . > > It was a VAX artifact and not very usable. I belive we have a couple > of comments and macros which still talk about "clicks". Like Jeff's patch, Mach's VM design allowed for two distinct page sizes, one being the native, hardware page size and the other being a larger, abstract page size. The essential difference between Jeff's patch and what Mach did on the VAX is that Mach's use of the native, hardware page size was entirely within the pmap and locore-level code. For example, the hardware-supported page size on the VAX was 512 bytes. However, as far as the machine-independent layer of the Mach kernel was concerned the page size was 4K bytes. This included the machine-independent part of the virtual memory system; it too believed that the page size was 4K bytes. As a consequences, the granularity of mappings and protection was 4K bytes. Finally, there was nothing VAX-specific about the design and implementation of this feature. However, I don't recall any other pmap implementations having different native and abstract page sizes. Today, I speculate that you could implement a distinct native and abstract page size on the sparc because different versions of processor have had different page sizes. Consequently, the ABI documents that I've seen don't specify a particular page size only that 64K bytes is the largest that a page will ever be; to learn the precise page size, they say that you must call the OS at run time. So, you could use a larger abstract page without breaking the ABI. In constrast, Jeff's patch has both the machine-dependent and machine-independent layers knowing about both page sizes. Moreover, the granularity of mappings and protection is still the native, hardware page size. In other words, within the vm_map the page size is the native, hardware page size, but over in the vm_object the page size is the larger, abstract size. (Reread the last sentence again before continuing.) As you can imagine, this is a lot trickier to get right in the first place and maintain in the long run than what Mach did. This is why Jeff is being so circumspect about committing this work. Other the hand, it offers essentially the same benefits as what Mach did without breaking the i386 ABI. Alan