Date: Fri, 20 Jun 2003 08:57:56 -0700 From: Peter Wemm <peter@wemm.org> To: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> Cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/amd64/amd64 pmap.c Message-ID: <20030620155756.423C72A7EA@canning.wemm.org> In-Reply-To: <ybsu1alqk02.wl@ett.sat.t.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Hidetoshi Shimokawa wrote: > At Fri, 20 Jun 2003 14:04:53 +0900, > Hidetoshi Shimokawa wrote: > > > > At Thu, 19 Jun 2003 21:41:41 -0700, > > Peter Wemm wrote: > > > > > > Hidetoshi Shimokawa wrote: > > > > At Thu, 19 Jun 2003 12:02:04 -0700, > > > > Peter Wemm wrote: > > > > > > Modified files: > > > > > > sys/amd64/amd64 pmap.c > > > > > > Log: > > > > > > Fix direct map page table for 2GB+ physical memory. > > > > > > > > > > Thank you! :-) > > > > > > > > > > Cheers, > > > > > -Peter > > > > > > > > Do you have any plan to increase KVA up to 512GB? > > > > struct vm_page consumes 250MB space for 8GB memory. > > > > > > Yes, once I return from my trip, which should be next week. It shouldn't > > > be too hard, it probably is a relatively simple matter of increasing the > > > slots reserved for growing KVM, and teaching pmap_growkernel how to grow > > > downwards.... OK, maybe thats easier said than done. :-) > > > > I though there are something other than that to change KERNBASE. > > I understand what we should do. > > I made patch for that, > http://www.sat.t.u-tokyo.ac.jp/~simokawa/amd64/kva.patch.txt > (include /dev/kmem fix for direct map and debug code) I like the part about moving to -2GB (but see below), but I am unhappy about the /dev/mem part of the change. We need to be able to let /dev/mem reach the pci mapping space etc, and your change breaks that. > I failed to link kernel for 2GB+ KVA space (set KPDPI to (NPDPEPG-4)). > Linker produces the following errors: > > locore.o: In function `btext': > /usr/obj/amd64/export/home/src/sys/FireWire/{standard input}:53: relocation t runcated to fit: R_X86_64_32S .bss > cam.o: In function `cam_fetch_status_entry':/export/home/src/sys/cam/cam.c:18 7:relocation truncated to fit: R_X86_64_32S .text > ..... > > Do you have any idea? Yes. This is what I was talking about for growing the kernel downwards. gcc generates code that uses 32 bit signed relocations. This means that you can only link code that has symbols in the +/- 2GB range. This is why things like PTmap[] are #defines rather than symbols. So, what I had planned was to leave the kernel at -1GB, and grow new pdp's downwards below the code link address. Since they are all accessed via pointers rather than compile time symbols, we can do that. What I haven't finished thinking about is the implications of that. Do we leave KERNBASE at -1GB and have something like KVABASE for some of the places that test for 'if (va > KERNBASE) ...' and so on. Those would have to change to KVABASE. Or, do we move KERNBASE to the bottom address that we can grow downwards to? The problem with that is that some early bootstrap code knows that va = pa + KERNBASE, so that would all need to be fixed. I did not want to try this in the leadup to 5.1-R, but the dust seems to be settling now and it is time to resolve it (and some of the other problems I've mentioned before). Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030620155756.423C72A7EA>