From owner-freebsd-arch@FreeBSD.ORG Sat Jan 21 01:02:15 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 EE17916A41F; Sat, 21 Jan 2006 01:02:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6A6643D45; Sat, 21 Jan 2006 01:02:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 20 Jan 2006 17:02:14 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43D18816.3010909@elischer.org> Date: Fri, 20 Jan 2006 17:02:14 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Cox References: <43CD612E.2060002@elischer.org> <63333.1137536336@critter.freebsd.dk> <20060121003908.GD6017@cs.rice.edu> In-Reply-To: <20060121003908.GD6017@cs.rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, Poul-Henning Kamp , 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 01:02:15 -0000 Alan Cox wrote: >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. > > was this the reason that it was done in a different way? What was the reason to not do it entirely in the pmap layer (e.g. Mach). I know hte Maxh people were very proud of their implementation. It always appeared in their technical descriptions. The phrase "this is a lot trickier to [...] maintain in the long run" worries me.. There must be a reason to not go with the simpler approach.. What was it? >Alan > >