Date: Thu, 06 Dec 2001 00:36:43 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Varshavchick Alexander <alex@metrocom.ru> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 4G phisical memory kernel trap Message-ID: <3C0F2E1B.7F933520@mindspring.com> References: <Pine.GSO.4.21.0112061018260.9266-100000@apache.metrocom.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Varshavchick Alexander wrote: > > For this to work, you really MUST address the machdep.c problems. > > So how can it be done, are there any patches for machdep.c, or is it > solved in 4.4-stable kernel? Matt Dillon took a sideways stab at addressing a bit of these issues. They didn't do everything that I thought was needed, but he posted the diffs to the -current list, and may have committed them to -current (look for them there). > > > > I also suggest increasing the KVA space from 3G to 4G. > > You mean setting KVA_SPACE option in kernel config? I don't know. I don't think so, but it might work that way in -current. The FreeBSD Handbook has it amost right, but they neglect to give some important information. In /sys/conf/ldscript.i386, you have to change 0xc0100000 to be the base of the new KVA space (0xc0000000-0xffffffff is 1G, so 0x80100000 would make it 2G, and 0x40100000 would make it 3G. In addition, you will need to modify NKPT in the header file /sys/i386/include/pmap.h; it has a default value of 30. This is sufficient to support a total of 30720 page table entries, which are effectively page descriptors for 4k pages. This yields a KVA space of 120M. The initial mapping here doesn't need to fill all of the KVA space, it just needs to be enough to handle all the entries prior to the VM officially starting, after which the mappings can be increased via pmap_growkernel(). So it has to be large enough to handle the static preallocations which the VM system is told about later, but which can be used prior to it being started. If you are using RELENG_4_4 or later, you can carnk up the KVA_PAGES number to 256*3 (768). Before that, you will need to adjust both NKPT and KPDE. Though it's not obvious, the answer is 766 for SMP and 767 for non-SMP kernels. This corresponds to the value of kernbase (they don't seem to be connected to the KVA_PAGES option, meaning you have to do a modification to both, but I might have missed something; but this is the part missing from the handbook). The magic thing to know about is the off-by-one for the recursive mapping, and the second off-by-one for the SMP per processor private page mapping. > I'm afraid I can have problems figuring this thing out, can you please > give guidelines here? 4M pages are hard to make work right, unless you know what you are doing. I wrote a function to "4M-pageize" an exisiting contiguous mapping which was on a 4M boundary, but my previous employer wouldn't let me publish it. The only tricky part is giving the page table pages back to the VM system (unless you were to preallocate large chunks of memory in machdep.c to ensure that it was both physically and virtually contiguous, which is sometimes useful). I will cover where and how to do this for non-4M pages, in my article. > > I really should write an article for Daemon New on the FreeBSD > > startup process at boot time, to fill in the gaps behind Matt > > Dillon's articles on FreeBSD VM after it has been started up. > > I will start work on one. > > It will be great! I have another article or two on embedded systems to finish first, I think, but then I'll work on getting it together. It will probably be against 4.4, so don't expect that it will include KVM_PAGES, except briefly. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C0F2E1B.7F933520>