From owner-freebsd-bugs Tue Oct 31 13:10:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 690E237B479 for ; Tue, 31 Oct 2000 13:10:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id NAA92290; Tue, 31 Oct 2000 13:10:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Tue, 31 Oct 2000 13:10:03 -0800 (PST) Message-Id: <200010312110.NAA92290@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: David Greenman Subject: Re: i386/22441: pmap_growkernel() is not effective at kernel vm limit of 0xffc00000 Reply-To: David Greenman Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR i386/22441; it has been noted by GNATS. From: David Greenman To: William J Carpenter Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: i386/22441: pmap_growkernel() is not effective at kernel vm limit of 0xffc00000 Date: Tue, 31 Oct 2000 13:03:29 -0800 >I am not sure that what I am doing is strictly necessary, but >I can successfully allocate kernel vm this way in BSDI. > > but I > should point out that the alternate page table map (APTmap) starts > at 0xffc00000, so I don't see how you could ever use that area of > virtual memory without serious problems. What am I missing? > >That's good to know. > >The problem is that 0xffc00000 is passed as a limit to pmap_growkernel(). >I am not using 0xffc00000, I am using memory up to 0xffc00000 which >is the advertised limit to kernel vm. (kernel_map->header.end) > >(kgdb) print /x * kernel_map >$221 = {header = {prev = 0xc02c1d60, next = 0xc02c1f70, start = 0xbfeff000, > end = 0xffc00000, avail_ssize = 0x0, object = {vm_object = 0x0, > sub_map = 0x0}, offset = 0x0, eflags = 0x0, protection = 0x0, > max_protection = 0x0, inheritance = 0x0, wired_count = 0x0, lastr = 0x0}, > lock = {lk_interlock = {lock_data = 0x0}, lk_flags = 0x1000000, > lk_sharecount = 0x0, lk_waitcount = 0x0, lk_exclusivecount = 0x0, > lk_prio = 0x4, lk_wmesg = 0xc0277da0, lk_timo = 0x0, > lk_lockholder = 0xffffffff}, nentries = 0x9, size = 0x1e531000, > system_map = 0x1, hint = 0xc02c1d60, timestamp = 0x21, > first_free = 0xc02c1d00, pmap = 0xc02cf8c0} > >Pmap_growkernel()'s job is to set-up the physical page mappings to >cover the increased kernel vm. In order to do this on the i386 >architecture, a page map directory entry must be made for every >4mbytes of memory. The kernel vm layer rounds vm up to a page >boundary. The physical map layer must round-up a 4mbyte boundary >because of the two level i386 page mapping hierarchy. > >If the vm layer kernel memory limit falls on a page boundary, >but not on a page directory boundary, say 0xffb01000, >then as far as physical map layer is concerned, a page directory >entry must be created to cover vm from 0xffb00000 to 0xffbfffff. >If the vm layer limit falls on 0xffb00000, this means that >the kernel requested vm in the range 0xffaff000 to 0xffafffff. >The vm layer rounds this address up to 0xffb00000 and declares >that this is the limit for pmap_growkernel(). In the case where >the limit is 0xffb00000, pmap_growkernel actually makes a >page directory entry for adresses >= 0xffb00000 -- a harmless >sort of overflow which merely sucks up an extra page of memory. >In the case where the kernel vm grows to the range of >[ 0xffbff001, 0xffc00000-1 ], (the page below 0xffc00000, in this >case, kernel vm requested explicitly by me), pmap_growkernel() >overflows by rounding 0xffc0000 up to the next 4m boundary which >on 32-bit machines is 0. > >I hope this helps explain what I think is a problem. Your analysis appears to be correct, and using roundup() seems like a fine solution. All three rounding expressions in that function need to be changed to completely fix the problem. Thanks for the bug report! -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message