From owner-freebsd-arch@FreeBSD.ORG Mon Jan 16 04:43:36 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 B5D8316A41F; Mon, 16 Jan 2006 04:43:36 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A83C43D45; Mon, 16 Jan 2006 04:43:36 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.2] (c-24-6-173-198.hsd1.ca.comcast.net [24.6.173.198]) by elvis.mu.org (Postfix) with ESMTP id 5CCAE1A3C1B; Sun, 15 Jan 2006 20:43:36 -0800 (PST) Message-ID: <43CB246D.1050705@FreeBSD.org> Date: Sun, 15 Jan 2006 20:43:25 -0800 From: Suleiman Souhlal User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: arch@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [RFC/Benchmarks] Per-CPU freelists 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: Mon, 16 Jan 2006 04:43:36 -0000 Hello, I implemented per-CPU page freelists this weekend, in the hopes that it would improve performance on SMP machines, as it should save a spinlock acquisition in vm_page_alloc(), in most cases (except when VM_ALLOC_INTERRUPT is set, and when the current cpu's free list is empty), and reduce contention. However, I was only able to test it on machine with two CPUs, where it didn't seem to make any difference. You can set the number of pages that get added to the freelists each time it gets refilled in vm.pcpu.refill_num, and the maximum length of the freelists in vm.pcpu.max_len. Some stats are viewable in vm.pcpu.stats. The patch is available at http://people.freebsd.org/~ssouhlal/testing/pcpu-freelists-20060115.diff I would really appreciate if someone could benchmark/test this on a machine with more processors. Here's the output of ministat(1) for buildkernel: x refill_num=32, max_len=64 + refill_num=4, max_len=-1 (effectively disabling the percpu freelists) +--------------------------------------------------------------------------+ |+ + x x+ x + + x x| | |_____________|_______M_MA____________A____________|__________| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 171.64 172.09 171.69 171.816 0.21220273 + 5 171.44 171.97 171.67 171.702 0.22928149 No difference proven at 95.0% confidence -- Suleiman From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 08:44:38 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 0A0B616A41F; Tue, 17 Jan 2006 08:44:38 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EBEE43D48; Tue, 17 Jan 2006 08:44:37 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from [10.0.0.1] (67-40-203-22.tukw.qwest.net [67.40.203.22]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.1/8.13.1) with ESMTP id k0H8iX8P083583; Tue, 17 Jan 2006 03:44:34 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Tue, 17 Jan 2006 00:42:57 -0800 (PST) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: arch@freebsd.org Message-ID: <20060117002541.I602@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.52 on 216.240.101.25 Cc: alc@freebsd.org Subject: 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: Tue, 17 Jan 2006 08:44:38 -0000 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: 1) Shrinking the size of the vm page array so that very large memory x86 PAE machines may boot. 2) Improving performance of many operations due to decreased page list sizes as well as improved efficiency of many vm operations. In the particular application that this was developed for the fs block size, page size, and jumbo frame size were all made equal at 8k on a box with 4k pages. This made page flipping etc. very fast. This has been done with full userland backwards compatibility. Userland still has the ability to map things in native page size chunks. The majority of the system software remains unchanged. The vm gains some complexity and the elf loader gains some complexity since both need to be able to deal with native page size and virtual page size. The real page size is now CPU_PAGE_SIZE while PAGE_SIZE is the virtual page size which is the smallest unit of memory handed back by the page allocation routines. KVA is also managed in PAGE_SIZE chunks. The x86 pmap code has a small allocator that deals with allocating real pages for page table entries. I wrote this code for a client who would like for it to be in the freebsd tree. However, it does add some complexity and so I doubt freebsd wants it unless there is a clear demand for it. What I'd like to know is, does anyone else find this useful? Do the developers who work on the vm think this is just a horrible hack? Does anyone care about PAE anymore? Let me know what you think. The patch is available at http://www.chesapeake.net/~jroberson/8k.diff. It will not apply to any version of freebsd that you have. Please consider it read only and not testable until I decide whether it's worth porting. Cheers, Jeff From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 11:05:58 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 8534216A41F; Tue, 17 Jan 2006 11:05:58 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A2FF43D45; Tue, 17 Jan 2006 11:05:57 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 2A33FBC74; Tue, 17 Jan 2006 11:05:55 +0000 (UTC) To: Jeff Roberson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 17 Jan 2006 00:42:57 PST." <20060117002541.I602@10.0.0.1> Date: Tue, 17 Jan 2006 12:05:55 +0100 Message-ID: <56322.1137495955@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: alc@freebsd.org, 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: Tue, 17 Jan 2006 11:05:58 -0000 In message <20060117002541.I602@10.0.0.1>, Jeff Roberson writes: >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: Sounds like a good thing to me. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 18:18:45 2006 Return-Path: X-Original-To: freebsd-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 38C3616A41F for ; Tue, 17 Jan 2006 18:18:45 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id E01F943D46 for ; Tue, 17 Jan 2006 18:18:44 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id C629C5E48AA; Tue, 17 Jan 2006 10:18:44 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 3C4515E48AA for ; Tue, 17 Jan 2006 10:18:44 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <185CB7FA-438D-4D01-B673-2081A6B462CD@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-arch@freebsd.org From: Jason Evans Date: Tue, 17 Jan 2006 10:18:41 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Subject: RB_GENERATE macro problem 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: Tue, 17 Jan 2006 18:18:45 -0000 Andrey Chernov pointed out that jemalloc has several public symbols that should be static. Among the offending symbols are those generated by the RB_GENERATE macro in sys/tree.h. RB_GENERATE provides no mechanism for making the generated functions static, so I'd like to create new interfaces: RB_PROTOTYPE_STATIC and RB_GENERATE_STATIC. This does not introduce any incompatibilities, as far as I know. There is a complete patch at: http://people.freebsd.org/~jasone/patches/RB_static.diff In short, this patch does the following: -------- #define RB_GENERATE(name, type, field, cmp) \ RB_GENERATE_INTERNAL(name, type, field, cmp,) #define RB_GENERATE_STATIC(name, type, field, cmp) \ RB_GENERATE_INTERNAL(name, type, field, cmp, static) #define RB_GENERATE_INTERNAL(name, type, field, cmp, attr) \ attr void \ name##_RB_INSERT_COLOR(struct name *head, struct type *elm) \ [...] -------- Does anyone have any reservations about this change, or suggestions for a better method? Thanks, Jason From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 21:27:10 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 EE57216A41F; Tue, 17 Jan 2006 21:27:10 +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 AC27C43D46; Tue, 17 Jan 2006 21:27:10 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.146]) ([10.251.23.146]) by a50.ironport.com with ESMTP; 17 Jan 2006 13:27:11 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43CD612E.2060002@elischer.org> Date: Tue, 17 Jan 2006 13:27:10 -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: Jeff Roberson References: <20060117002541.I602@10.0.0.1> In-Reply-To: <20060117002541.I602@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, 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: Tue, 17 Jan 2006 21:27:11 -0000 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 always seemed like in interesting idea and I'm happy to see that it is still being looked at. > > 1) Shrinking the size of the vm page array so that very large memory > x86 PAE machines may boot. > > 2) Improving performance of many operations due to decreased page list > sizes as well as improved efficiency of many vm operations. In the > particular application that this was developed for the fs block size, > page size, and jumbo frame size were all made equal at 8k on a box > with 4k pages. This made page flipping etc. very fast. > > This has been done with full userland backwards compatibility. > Userland still has the ability to map things in native page size > chunks. The majority of the system software remains unchanged. The > vm gains some complexity and the elf loader gains some complexity > since both need to be able to deal with native page size and virtual > page size. > > The real page size is now CPU_PAGE_SIZE while PAGE_SIZE is the virtual > page size which is the smallest unit of memory handed back by the page > allocation routines. KVA is also managed in PAGE_SIZE chunks. The > x86 pmap code has a small allocator that deals with allocating real > pages for page table entries. > > I wrote this code for a client who would like for it to be in the > freebsd tree. However, it does add some complexity and so I doubt > freebsd wants it unless there is a clear demand for it. What I'd like > to know is, does anyone else find this useful? Do the developers who > work on the vm think this is just a horrible hack? Does anyone care > about PAE anymore? > > Let me know what you think. The patch is available at > http://www.chesapeake.net/~jroberson/8k.diff. It will not apply to > any version of freebsd that you have. Please consider it read only > and not testable until I decide whether it's worth porting. > > Cheers, > Jeff > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 21:48:46 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 6E1AF16A420; Tue, 17 Jan 2006 21:48:46 +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 1FF0043D49; Tue, 17 Jan 2006 21:48:44 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.146]) ([10.251.23.146]) by a50.ironport.com with ESMTP; 17 Jan 2006 13:48:44 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43CD663B.6010703@elischer.org> Date: Tue, 17 Jan 2006 13:48:43 -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: Julian Elischer References: <20060117002541.I602@10.0.0.1> <43CD612E.2060002@elischer.org> In-Reply-To: <43CD612E.2060002@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, 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: Tue, 17 Jan 2006 21:48:46 -0000 Julian Elischer wrote: > 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" . I can't see any record of it in our CVS files but I distinctly remember it in MACH. Not sure when it was removed. > > It always seemed like in interesting idea and I'm happy to see that it > is still being looked at. > From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 22:18:59 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 4F1AD16A420; Tue, 17 Jan 2006 22:18:59 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id E671343D46; Tue, 17 Jan 2006 22:18:58 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id AE2F2BC74; Tue, 17 Jan 2006 22:18:56 +0000 (UTC) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 17 Jan 2006 13:27:10 PST." <43CD612E.2060002@elischer.org> Date: Tue, 17 Jan 2006 23:18:56 +0100 Message-ID: <63333.1137536336@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: alc@freebsd.org, 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: Tue, 17 Jan 2006 22:18:59 -0000 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". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 22:31:37 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 721F316A41F; Tue, 17 Jan 2006 22:31:37 +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 1A29543D6D; Tue, 17 Jan 2006 22:31:37 +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 5E1414AA2E; Tue, 17 Jan 2006 16:31:36 -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 31459-01-22; Tue, 17 Jan 2006 16:31:35 -0600 (CST) Received: by cs.rice.edu (Postfix, from userid 19572) id B23414AA5A; Tue, 17 Jan 2006 16:31:35 -0600 (CST) Date: Tue, 17 Jan 2006 16:31:35 -0600 From: Alan Cox To: Poul-Henning Kamp Message-ID: <20060117223135.GB2360@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: Tue, 17 Jan 2006 22:31:37 -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". > It was not a VAX artifact. Also, Jeff's work differs significantly from what Mach did on the VAX. I'll explain the differences after my paper deadline passes tomorrow. Alan From owner-freebsd-arch@FreeBSD.ORG Wed Jan 18 20:08:31 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 3887916A41F; Wed, 18 Jan 2006 20:08:31 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DCEE43D4C; Wed, 18 Jan 2006 20:08:30 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail11.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k0IK8JTv002024 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 Jan 2006 07:08:19 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id k0IK8IHh025372; Thu, 19 Jan 2006 07:08:18 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id k0IK8IBM025371; Thu, 19 Jan 2006 07:08:18 +1100 (EST) (envelope-from pjeremy) Date: Thu, 19 Jan 2006 07:08:18 +1100 From: Peter Jeremy To: Jeff Roberson Message-ID: <20060118200818.GC24570@cirb503493.alcatel.com.au> References: <20060117002541.I602@10.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060117002541.I602@10.0.0.1> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: alc@freebsd.org, 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: Wed, 18 Jan 2006 20:08:31 -0000 On Tue, 2006-Jan-17 00:42:57 -0800, 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: > >1) Shrinking the size of the vm page array so that very large memory x86 >PAE machines may boot. > >2) Improving performance of many operations due to decreased page list >sizes as well as improved efficiency of many vm operations. In the I presume this would also reduce the KVA size on non-PAE large memory i386 systems. The code looks quite clean - I'd say it's a worthwhile addition to FreeBSD. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Thu Jan 19 07:48:31 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 6851E16A41F; Thu, 19 Jan 2006 07:48:31 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id C349C43D46; Thu, 19 Jan 2006 07:48:30 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5E445.dip.t-dialin.net [84.165.228.69]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id k0J7fYQN057826; Thu, 19 Jan 2006 08:41:35 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id k0J7mRm5025522; Thu, 19 Jan 2006 08:48:27 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 19 Jan 2006 08:48:27 +0100 Message-ID: <20060119084827.lsj89qu01wgogogs@netchild.homeip.net> X-Priority: 3 (Normal) Date: Thu, 19 Jan 2006 08:48:27 +0100 From: Alexander Leidinger To: arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: ru@FreeBSD.org Subject: The cause of the build problems with ccache 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: Thu, 19 Jan 2006 07:48:31 -0000 Hi, I looked at the cause of the build errors when using ccache. When building with ccache, the compiler uses /usr/include instead of the includes in /usr/src (after the "unsigned char" -> "void" change in the md5 header this jumps directly into your face if you look at the error message). Does the intermediate compiler in /usr/obj get build with a different default include path? If yes: - This would also result in picking up the wrong includes when someone tries to build the world with a different compiler (e.g. icc). - Wouldn't it be better to discard the default include path and add the include path we want explicitly on the command line? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Courage is your greatest present need. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 19 12:57:29 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 6332916A420 for ; Thu, 19 Jan 2006 12:57:29 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06CC343D46 for ; Thu, 19 Jan 2006 12:57:27 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id k0JCvQNR058645; Thu, 19 Jan 2006 14:57:26 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ip.net.ua [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 07616-01; Thu, 19 Jan 2006 14:57:21 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id k0JCpTIt058513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2006 14:51:29 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id k0JCpP3g052540; Thu, 19 Jan 2006 14:51:25 +0200 (EET) (envelope-from ru) Date: Thu, 19 Jan 2006 14:51:25 +0200 From: Ruslan Ermilov To: Alexander Leidinger Message-ID: <20060119125124.GB52459@ip.net.ua> References: <20060119084827.lsj89qu01wgogogs@netchild.homeip.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kORqDWCi7qDJ0mEj" Content-Disposition: inline In-Reply-To: <20060119084827.lsj89qu01wgogogs@netchild.homeip.net> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: arch@freebsd.org Subject: Re: The cause of the build problems with ccache 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: Thu, 19 Jan 2006 12:57:29 -0000 --kORqDWCi7qDJ0mEj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 19, 2006 at 08:48:27AM +0100, Alexander Leidinger wrote: > Hi, >=20 > I looked at the cause of the build errors when using ccache. When building > with ccache, the compiler uses /usr/include instead of the includes in > /usr/src (after the "unsigned char" -> "void" change in the md5 header th= is > jumps directly into your face if you look at the error message). >=20 > Does the intermediate compiler in /usr/obj get build with a different def= ault > include path? >=20 Yes. The magic is in this line in Makefile.inc1: XMAKE=3D TOOLS_PREFIX=3D${WORLDTMP} ${BMAKE} -DNO_FORTRAN -DNO_GDB ^^^^^^^^^^^^^^^^^^^^^^^^ > If yes: > - This would also result in picking up the wrong includes when someone t= ries > to build the world with a different compiler (e.g. icc). >=20 I believe so. > - Wouldn't it be better to discard the default include path and add the > include path we want explicitly on the command line? >=20 This was attempted before and failed. I don't remember all the details now (you can also go ask Marcel and David), but I remember GCC is picky about standard paths: it would treat them differently from other locations, resulting in a different set of warnings etc. And we want it to work exactly as if these paths were standard. The compiler set uses stuff in ${WORLDTMP}: new headers, libraries, etc. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --kORqDWCi7qDJ0mEj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDz4tMqRfpzJluFF4RAo8ZAKCby4rCehBJqxVnaTx4+OLQD6LBqwCePAyS cM9Z3OSffo/OL/YLDbeEy48= =5y/G -----END PGP SIGNATURE----- --kORqDWCi7qDJ0mEj-- From owner-freebsd-arch@FreeBSD.ORG Thu Jan 19 13:06:53 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 4581816A426; Thu, 19 Jan 2006 13:06:53 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7386C43D5E; Thu, 19 Jan 2006 13:06:50 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 5651DAD; Thu, 19 Jan 2006 07:06:50 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 7CDB761C2B; Thu, 19 Jan 2006 07:06:49 -0600 (CST) Date: Thu, 19 Jan 2006 07:06:49 -0600 From: "Matthew D. Fuller" To: Ruslan Ermilov Message-ID: <20060119130649.GW63244@over-yonder.net> References: <20060119084827.lsj89qu01wgogogs@netchild.homeip.net> <20060119125124.GB52459@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060119125124.GB52459@ip.net.ua> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: Alexander Leidinger , arch@freebsd.org Subject: Re: The cause of the build problems with ccache 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: Thu, 19 Jan 2006 13:06:53 -0000 On Thu, Jan 19, 2006 at 02:51:25PM +0200 I heard the voice of Ruslan Ermilov, and lo! it spake thus: > > but I remember GCC is picky about standard paths: it would treat > them differently from other locations, resulting in a different set > of warnings etc. Note that gcc does have a "-isystem" (as opposed to -I) that I think mostly handles this sort of thing. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 19 19:43:49 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 7815816A41F; Thu, 19 Jan 2006 19:43:49 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2747543D45; Thu, 19 Jan 2006 19:43:48 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost.xcllnt.net [127.0.0.1]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id k0JJhmcR011982; Thu, 19 Jan 2006 11:43:48 -0800 (PST) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.13.4/8.13.4/Submit) id k0JJhlPc011981; Thu, 19 Jan 2006 11:43:47 -0800 (PST) (envelope-from marcel) Date: Thu, 19 Jan 2006 11:43:47 -0800 From: Marcel Moolenaar To: Ruslan Ermilov Message-ID: <20060119194347.GA68946@ns1.xcllnt.net> References: <20060119084827.lsj89qu01wgogogs@netchild.homeip.net> <20060119125124.GB52459@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060119125124.GB52459@ip.net.ua> User-Agent: Mutt/1.4.2.1i Cc: Alexander Leidinger , arch@freebsd.org Subject: Re: The cause of the build problems with ccache 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: Thu, 19 Jan 2006 19:43:49 -0000 On Thu, Jan 19, 2006 at 02:51:25PM +0200, Ruslan Ermilov wrote: > > > - Wouldn't it be better to discard the default include path and add the > > include path we want explicitly on the command line? > > > This was attempted before and failed. I don't remember all the details > now (you can also go ask Marcel and David), but I remember GCC is picky > about standard paths: it would treat them differently from other > locations, resulting in a different set of warnings etc. And we want > it to work exactly as if these paths were standard. The compiler set > uses stuff in ${WORLDTMP}: new headers, libraries, etc. True. Cross-building was implemented in the days when Perl was still in the tree. A lot (if not all) of the obvious solutions simply didn't work because the Perl buildtools weren't parameterized. The only option was to change the behaviour of the compiler under the hood. Now that we don't have to worry about Perl anymore, it's more likely that we can use standard GCC options. Just keep in mind that a cross compiler tends to behave differently from a native compiler. They certainly did back then. There may be goblins still... See also rev 1.16 of src/contrib/gcc/gcc.c. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net 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 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 > >