Skip site navigation (1)Skip section navigation (2)
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>