Date: Sun, 20 Feb 2000 16:28:51 +1100 From: Patryk Zadarnowski <patrykz@ilion.eu.org> To: Arun Sharma <adsharma@sharmas.dhs.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 64bit OS? Message-ID: <200002200528.QAA04257@mycenae.ilion.eu.org> In-Reply-To: Your message of "Sat, 19 Feb 2000 20:58:50 -0800." <20000219205850.A24847@sharmas.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sun, Feb 20, 2000 at 01:48:49PM +1100, Patryk Zadarnowski wrote: > > > It looks like the hardware has to implement GPTs and know how to > > > walk them. How can FreeBSD use them without hardware support ? > > > > No it doesn't. We've got software GPT implementations for both MIPS64 and > > Alpha, and they're both peform very well in our somewhat hostile SASOS > > conditions. I'm not sure why you think that a hardware walk is necessary: > > For performance reasons and memory efficiency reasons. My understanding of We must be careful here. Although you're getting a samll immediate performance gain by not flushing the pipelines, the performance is killed if the working set is larger than the TLB (as it usually is on a moderately-loaded system, especially in presence of heavy IPC (eg. UNIX pipes)), in which case a smarter data structure will usually increase the TLB coverage. And don't forget that with VHPT you'll be getting nested TLB faults quite frequently in a sparsely-populated page table (think shared libraries). Efficiency-wise, Kevin has shown that you only need a fairly small VPHT, and it is global, so you ammortise the cost across all running tasks. Further, you can easily share a GPT or LPCtrie subtrees, at which stage the whole memory-wastage argument goes completely out of the window (I'm currently writing a microkernel that is intended to demonstrate just that on UltraSPARC which has an MMU vaguely resembling that of IA-64.). Besides, doesn't Linux duplicate the structure anyway even when it uses a hardware-walked page table? Avoiding data duplication isn't always a good thing: as a rule, caching helps. ;) > your proposal is - use VHPT as a large in memory TLB and use GPT as > operating system's primary page table. Precisely. > Doesn't that involve duplication of information in memory, especially if the > hash table is big ? No, not significantly, for two reasons: first, you don't need a huge VPHT -- 512KB is more than enough. Also, VPHT becomes a cache for the actual page table. It's been empirically demonstrated that 64 bit (esp. sparse 64 bit) page tables really need such a cache (software TLB) anyway. And it's the main way Intel planned VPHT to be used in the first place. The performance improvement tends to be significant (look at Kevin's PhD that I've posed before.) Besides, the amount of space saved due to a smarter page table data structure more than compensates for the additional memory anyway. > > the only reason why IA-64 walks VPHT in hardware *at all* is to minimize > > the impact on the pipeline and improve ILP: > > I think that's an important reason. A software only TLB miss handler > would be inferior to a VHPT based solution on IA-64, IMO. It's the only justification Rumi Zahir (head of the IA-64 team) gave me when I was complaining about it. (as in: ``why bother? 64 bit page tables are an open problem and no other 64 bit platform I know of provides a hardware page table walk''. BTW, does anoone know if HP-PA and IBM 64bit PPC implement a hardware PT walk? 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?200002200528.QAA04257>