Date: Sun, 20 Feb 2000 12:42:14 +1100 From: Patryk Zadarnowski <patrykz@ilion.eu.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Arun Sharma <adsharma@sharmas.dhs.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: 64bit OS? Message-ID: <200002200142.MAA03468@mycenae.ilion.eu.org> In-Reply-To: Your message of "Sat, 19 Feb 2000 12:13:25 -0800." <200002192013.MAA96756@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> :Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces > :and it turns out that hash tables perform quite poorly. I'd suggest GPTs > :instead, or maybe LPCtrie that Chris Szmajda has been working on here at UNSW. > :Both have the advantage of supporting multiple page sizes that IA64 (and > :Alpha) offer, and hence dramatically increasing the TLB coverage over what > :Linux (or any other commercial OS that took a bite at IA64) can achieve. > :Kevin's paper's at: > :ftp://ftp.cse.unsw.edu.au/pub/users/disy/papers/Elphinstone:phd.ps.gz > : > :Maybe that way we can somehow make use of the Itanium's 4GB page size ;)))) > : > :Pat. > > Linux has a good idea re: mapping all of real memory into KVM, it's > just one that doesn't work well on a 32 bit architecture :-). But on > a 64 bit architecture it can be seriously useful. At the very least > we can get rid of the private pmap pages and make pmap copying a much > faster operation. Actually, on IA64 this is not needed at all. The thing is, we've got eight regions accessible simultaneously (sort of like MIPS address space regions, only fully configurable, with per-region page table), so we can always reserve region 0 for user space, 1 for shared libraries, 2 for physical memory and 3 for KVM, and maybe even disable the page table for region 2, and use Keys to grant physical memory access permissions on demand. That way we don't waste TLB (umm... TC) entries for essentially one-to-one mappings. > I read Kevin's thesis. Facinating! The GPT concept is essentially What is even more fascinating about IA-64 that the software TLB that Kevin describes in his thesis can be walked in hardware, and hence can cache variable page sizes (although unfortunately not all the IA-64 pages sizes are supported by VPHT) The only other architecture that offers that is SPARC, but their software TLB supports only 4KB and 64KB page sizes, so all other pages must be reloaded directly from the page table. > a radix tree (and a degenerate version of the radix tree is, of course, > the normal two-level page table IA32 uses). All the memory and > performance issues Kevin brings up are exactly the same memory and > performance issues that a radix tree has. And he is bang-on in > regards to node sharing. With a normal page table node sharing is What's funny is that nobody (to the best of my knowledge) had the guts to implement node sharing or even variable page sizes in GPTs. They're a nightmare to code. Did I mention that we've been using them on MIPS and Alphas for few years now in our research SASOS? (and a few months on StrongARM, and soon on SPARCs ;) So they are field tested, and not just some piece of benchmark-based theorising. > difficult because each page in the page table represents a large area > of memory (4MB on IA32). But using a GPT we can potentially node-share > the bulk of the pages associated with shared libraries despite there > being COW'd pages in the middle of that space from the dynamic linking. LPCtires look even better. Have a look at http://www.cse.unsw.EDU.AU/~cls/cls.thesis.ps.gz they're designed *specifically* to promote variable pages sizes, and Chris claims that adding node sharing to his current implementation (he's got an almost-generic one that works on MIPS 4K, all Alphas and theoretically SPARCs) would be trivial. One more thing about GPTs (I thought I'll leave that till last. ;) Jochen Liedtke holds a German patent on them, although he will probably be fairly easily convinced to give FreeBSD rights to use them. I'll be happy to ask (if we're interested.) Pat. 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?200002200142.MAA03468>