Date: Tue, 31 Oct 2000 13:10:03 -0800 (PST) From: David Greenman <dg@root.com> To: freebsd-bugs@FreeBSD.org Subject: Re: i386/22441: pmap_growkernel() is not effective at kernel vm limit of 0xffc00000 Message-ID: <200010312110.NAA92290@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/22441; it has been noted by GNATS.
From: David Greenman <dg@root.com>
To: William J Carpenter <carp@world.std.com>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010312110.NAA92290>