64bit OS?

[Steve Ames]

Just read this article:

http://www.zdnet.com/zdnn/stories/news/0,4586,2440002,00.html

Which leads to my potentially ignorant question: Where is FreeBSD
w/regards to running on the Itanium (or other 64bit chips)?

-Steve


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Arun Sharma]

Arun Sharma wrote:
> Matt Dillon wrote:
> > What I would truely love to do would be to get away with not using a GPT
> > at all and instead doing a vm_map_lookup_entry()/vm_page_lookup()
> > (essentially taking a vm_fault), then optimize the vm_map_entry 
> > structural hierarchy to look more like a GPT rather then the linear 
> > list it currently is.  When coupled with an STLB, especially one that 
> > can be optimized, I think performance would be extremely good.
> 
> For finding the vm_map_entry for a virtual address, a balanced binary tree 
> works better. Linux does well here - it uses AVL trees, which find the
> right vm_map_entry in O(log n) time.

I just did some investigation into seeing if this (balanced binary trees)
is a useful optimization. It doesn't look like one. 

I instrumented the kernel and collected some stats. On booting the kernel
into KDE and running xemacs and netscape, I got:

kern.vm_map_nsteps: 151916
kern.vm_map_nlookups: 65441

i.e. roughly 3 vm_map_entries were walked before getting to the right one.

Then I did a make clean all; in /usr/src/sys and at the end of the compilation,
I got:

kern.vm_map_nsteps: 666258
kern.vm_map_nlookups: 628911

This time the hints seemed to have worked extremely well and there is almost
no overhead involved.

These numbers would be valid even for 64 bit architectures. However, if
the number of apps which use a large number of shared libraries or loadable
modules (Mozilla with XPCOM, KDE with KOM/DCOP) things can be slightly
different.

For now, I think we're just fine with linear linked lists with a hint.

-Arun

*** vm_map.c-   Sat Feb 26 12:01:59 2000
--- vm_map.cSat Feb 26 12:13:46 2000
***
*** 75,80 
--- 75,83 
  #include 
  #include 
  #include 
+ #include 
+ #include 
+ #include 
  
  #include 
  #include 
***
*** 331,336 
--- 334,349 
  #define   SAVE_HINT(map,value) \
(map)->hint = (value);
  
+ /* Some counters for tracking the overhead of servicing page faults */
+ static unsigned long nsteps = 0;
+ static unsigned long nlookups = 0;
+ 
+ SYSCTL_LONG(_kern, OID_AUTO, vm_map_nsteps, CTLFLAG_RW, 
+   &nsteps, "");
+ 
+ SYSCTL_LONG(_kern, OID_AUTO, vm_map_nlookups, CTLFLAG_RW, 
+   &nlookups, "");
+ 
  /*
   *vm_map_lookup_entry:[ internal use only ]
   *
***
*** 350,355 
--- 363,370 
vm_map_entry_t cur;
vm_map_entry_t last;
  
+   nlookups++;
+ 
/*
 * Start looking either from the head of the list, or from the hint.
 */
***
*** 401,406 
--- 416,422 
break;
}
cur = cur->next;
+   nsteps++;
}
*entry = cur->prev;
SAVE_HINT(map, *entry);


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Jordan K. Hubbard]

> Which leads to my potentially ignorant question: Where is FreeBSD
> w/regards to running on the Itanium (or other 64bit chips)?

Waiting for somebody at Intel to give us either hardware or simulator
time.  Without either of those things, "working on" Itanium support
is a pretty pointless exercise.

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Steve Ames]

On Thu, Feb 17, 2000 at 02:26:16PM -0800, Jordan K. Hubbard wrote:
> > Which leads to my potentially ignorant question: Where is FreeBSD
> > w/regards to running on the Itanium (or other 64bit chips)?
> 
> Waiting for somebody at Intel to give us either hardware or simulator
> time.  Without either of those things, "working on" Itanium support
> is a pretty pointless exercise.

A pretty tricky exercise also. Thanks for the quick response Jordan.

-steve


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> 
> Just read this article:
> 
> http://www.zdnet.com/zdnn/stories/news/0,4586,2440002,00.html
> 
> Which leads to my potentially ignorant question: Where is FreeBSD
> w/regards to running on the Itanium (or other 64bit chips)?

Considering the fact that Intel released the IA-64 OS info only on the 15th,
and, to my knowledge, haven't signed any NDA's with anyone from the FreeBSD
team, I'd assume that we're precisely nowhere. ;)

Having said that, I'll be getting Itanium hardware fairly soon after it's
avaliable outside of Intel, and would be ultra-happy to work on an IA-64
FreeBSD when that happens. In the meantime, the only alternative would be to
convince Intel to give someone their IA-64 SimOS, but there's an extermely
slim chance of that happening (from talking to someone on the IA-64 team.)

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Steve Kargl]

Patryk Zadarnowski wrote:
> FreeBSD when that happens. In the meantime, the only alternative would be to
> convince Intel to give someone their IA-64 SimOS, but there's an extermely
> slim chance of that happening (from talking to someone on the IA-64 team.)
> 

An alternative to IA-64 is the alpha processor.  Last time
I checked, FreeBSD ran just peachy on a 64-bit processor. ;-)
Check out Cmpaq's test drive program.


-- 
Steve


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> Patryk Zadarnowski wrote:
> > FreeBSD when that happens. In the meantime, the only alternative would be to
> > convince Intel to give someone their IA-64 SimOS, but there's an extermely
> > slim chance of that happening (from talking to someone on the IA-64 team.)
> > 
> 
> An alternative to IA-64 is the alpha processor.  Last time
> I checked, FreeBSD ran just peachy on a 64-bit processor. ;-)
> Check out Cmpaq's test drive program.

I don't know... I'm still to get it to boot on mine (NetBSD runs fine, but for
some bizzare reason, FreeBSD insists on a serial console ;) Anyway, alphas are
boring compared to Itanium. What else can you say about a chip with 3MB of L3
cache on the die, a four clock cycle latency to carry the signal from one end
of the chip to the other, and the main design limitation being the US power
supplies? :) Not to mention the fact that Intel isn't even planning to release
any single-cpu system

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Mike Smith]

> > An alternative to IA-64 is the alpha processor.  Last time
> > I checked, FreeBSD ran just peachy on a 64-bit processor. ;-)
> > Check out Cmpaq's test drive program.
> 
> I don't know... I'm still to get it to boot on mine (NetBSD runs fine, but for
> some bizzare reason, FreeBSD insists on a serial console ;) Anyway, alphas are
> boring compared to Itanium. What else can you say about a chip with 3MB of L3
> cache on the die, a four clock cycle latency to carry the signal from one end
> of the chip to the other, and the main design limitation being the US power
> supplies? :) Not to mention the fact that Intel isn't even planning to release
> any single-cpu system

What can one say to that, apart from "I have one right here and it works 
just fine" - not something you can say about the IA-64. 8)

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Marco van de Voort]

> > Which leads to my potentially ignorant question: Where is FreeBSD
> > w/regards to running on the Itanium (or other 64bit chips)?
> 
> Waiting for somebody at Intel to give us either hardware or simulator
> time.  Without either of those things, "working on" Itanium support
> is a pretty pointless exercise.

Just a thought:

One could use the released 64-bit Itanium gcc, create a i386->itanium 
crosscompiler, and start preparing some stuff?
Marco van de Voort ([EMAIL PROTECTED])




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Sam Leffler]

- Original Message -
From: "Marco van de Voort" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 17, 2000 3:30 PM
Subject: Re: 64bit OS?


> > > Which leads to my potentially ignorant question: Where is FreeBSD
> > > w/regards to running on the Itanium (or other 64bit chips)?
> >
> > Waiting for somebody at Intel to give us either hardware or simulator
> > time.  Without either of those things, "working on" Itanium support
> > is a pretty pointless exercise.
>
> Just a thought:
>
> One could use the released 64-bit Itanium gcc, create a i386->itanium
> crosscompiler, and start preparing some stuff?
> Marco van de Voort ([EMAIL PROTECTED])
> <http://www.stack.nl/~marcov/xtdlib.htm>
>

The difficult bits rarely have anything to do with compilers and such
(especially given that most of the code has been through a 64-bit port to
the alpha).  The system-mode pieces of IA-64/Merced were not public until
recently; I noticed the full document set just became available on the intel
web site this week. There's also the Linux port that was posted to the web
in the past week or two; that should show what's needed for a FreeBSD port.

Of course, as was mentioned before, without hardware or a simulator it's
pretty pointless to put much effort into something like this.

Sam



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[David Scheidt]

On Fri, 18 Feb 2000, Patryk Zadarnowski wrote:

> 
> I don't know... I'm still to get it to boot on mine (NetBSD runs fine, but for
> some bizzare reason, FreeBSD insists on a serial console ;) Anyway, alphas are
> boring compared to Itanium. What else can you say about a chip with 3MB of L3
> cache on the die, a four clock cycle latency to carry the signal from one end
> of the chip to the other, and the main design limitation being the US power
> supplies? :) Not to mention the fact that Intel isn't even planning to release
> any single-cpu system

"I could have had a PA-8600!"?  Today, and not at some vague point in the
future?


David



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> > > > Which leads to my potentially ignorant question: Where is FreeBSD
> > > > w/regards to running on the Itanium (or other 64bit chips)?
> > >
> > > Waiting for somebody at Intel to give us either hardware or simulator
> > > time.  Without either of those things, "working on" Itanium support
> > > is a pretty pointless exercise.
> >
> > Just a thought:
> >
> > One could use the released 64-bit Itanium gcc, create a i386->itanium
> > crosscompiler, and start preparing some stuff?
> > Marco van de Voort ([EMAIL PROTECTED])
> > 
> >
> 
> The difficult bits rarely have anything to do with compilers and such
> (especially given that most of the code has been through a 64-bit port to
> the alpha).  The system-mode pieces of IA-64/Merced were not public until
> recently; I noticed the full document set just became available on the intel
> web site this week. There's also the Linux port that was posted to the web
> in the past week or two; that should show what's needed for a FreeBSD port.

The Linux port is extremely minimalistic and uses the minimum amout of IA-64
features to get the OS to do anything useful.

> Of course, as was mentioned before, without hardware or a simulator it's
> pretty pointless to put much effort into something like this.

Also, you'll find that the actual silicon is somewhat different from the
documentation: whole chunks of the architecture are either unimplemented or
covered by errata, and not planned to be fixed in the public Itanium
silicon. The OS teams that signed NDAs with Intel (including the Linux team:
most of their code has been written by IA-64 teams at Intel and HP) have been
cooperating very closely with Intel and were given a lot of information that
(most of us) can only dream about. That is to say: even the simulator wouldn't
help much right now.

On the other hand, IA-64 is a very exotic architecture from the OS's point of
view, and anyone planning to port *BSD to it should probably start planning
ASAP.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> "I could have had a PA-8600!"?  Today, and not at some vague point in the
> future?

That sort-of misses the point, as I'm taking a research OS perspective, where
IA-64 is trully unique in terms of versitality and a well thought-through
design (especially when it comes to SASOS support!) Besides, that point in the
future is not all that vague at all ;)

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Mike Nowlin]

> What can one say to that, apart from "I have one right here and it works 
> just fine" - not something you can say about the IA-64. 8)

I'll just reach down and pat my trusty pair of manufactured-in-1993 Alpha
3000's on their heads...  :)

Oh, forgot...  It's not new until Intel does it...  sorry...

mike




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> 
> > What can one say to that, apart from "I have one right here and it works 
> > just fine" - not something you can say about the IA-64. 8)
> 
> I'll just reach down and pat my trusty pair of manufactured-in-1993 Alpha
> 3000's on their heads...  :)
> 
> Oh, forgot...  It's not new until Intel does it...  sorry...
> 
> mike

You're being just plain silly.  It takes about 5 minutes with the
manuals to realize just how little AXP and IA-64 have in common: one
is a classic superscalar out-of-order design, the other is just about
the opposite: a typical explicit-ILP architecture. What makes IA-64
great is the 8 years of statistical analysis of real-life software the
architecture design team spent fine-tuning the instruction set. What
makes AXP great is the clock rates Digital/Compaq manages to pump into
the beasts ;)

And no, there's nothing fundamentally new in IA-64 apart from the fact
that they're the last kids on the block with a 64 bit chip ;)

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Wilko Bulte]

On Thu, Feb 17, 2000 at 05:19:21PM -0500, Steve Ames wrote:
> 
> Just read this article:
> 
> http://www.zdnet.com/zdnn/stories/news/0,4586,2440002,00.html
> 
> Which leads to my potentially ignorant question: Where is FreeBSD
> w/regards to running on the Itanium (or other 64bit chips)?

FreeBSD runs very well on the Alpha, which is a 64 bit chip. There is
plenty of 'vapor silicon' (as opposed to vaporware) out there, but until
64 bit chips can be bought readily in the PC world the Alpha port is the 64
bit flagship.

-- 
Wilko Bulte Arnhem, The Netherlands   
http://www.tcja.nl  The FreeBSD Project: http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Daniel C. Sobral]

Patryk Zadarnowski wrote:
> 
> You're being just plain silly.  It takes about 5 minutes with the
> manuals to realize just how little AXP and IA-64 have in common: one
> is a classic superscalar out-of-order design, the other is just about
> the opposite: a typical explicit-ILP architecture. What makes IA-64
> great is the 8 years of statistical analysis of real-life software the
> architecture design team spent fine-tuning the instruction set. What
> makes AXP great is the clock rates Digital/Compaq manages to pump into
> the beasts ;)

What makes IA-64 great is the fact that it has not been deployed, so
Intel can say whatever it pleases them.

If you got REAL LIFE NUMBERS, based on REAL LIFE PERFORMANCE, then we
can talk. Let's see how it does Quake, then we can talk.

--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]

"If you consider our help impolite, you should see the manager."


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Jordan K. Hubbard]

> If you got REAL LIFE NUMBERS, based on REAL LIFE PERFORMANCE, then we
> can talk. Let's see how it does Quake, then we can talk.

Alpha does quake? :-)

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Ed Hall]

: Alpha does quake? :-)

It supposedly does under Linux, at least (and if you're talking about
Quake I).  Sources at:

http://www.idsoftware.com/q1source/

These sources might need a bit of work, even for Linux, though there
are folks out there who have it running under Linux/Alpha.  I'd assume
a FreeBSD port would only be moderately difficult, if that.

This is the sum total of what I know about this...

-Ed




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Arun Sharma]

[ My apologies if this is a repeat - my earlier mail didn't seem to make it ]

On Fri, 18 Feb 2000 12:03:37 +1100, Patryk Zadarnowski <[EMAIL PROTECTED]> wrote:

> On the other hand, IA-64 is a very exotic architecture from the OS's
> point of view, and anyone planning to port *BSD to it should probably
> start planning ASAP.

I'm a former Intel employee and I have worked on the Linux IA-64 project.
I think there is plenty of planning to do to get an OS running on
IA-64, which is more complex than most other architectures I've known.

First of all - there is plenty of reading to do:

http://developer.intel.com/design/ia-64/manuals/index.htm
http://devresource.hp.com/devresource/Docs/Refs/IA64ISA/index.html

Some of the design decisions to make:

(a) Programming model - LP64 would probably be the most sensible
(b) Page table architecture

IA-64 supports both the long and short format VHPT (virtual hash page
table). Linux chose to use the short format - which really uses no
hashing. 

Linux has the concept of machine independent multi level page tables and
has generic algorithms which manipulate them in machine independent code.
Where possible, it tries to map them to hardware dependent page tables.
On architectures like IA-64 and Power PC, this becomes a little awkward
and Linux essentially treats hardware page tables as TLBs.

The problem with the above approach is duplication of information between
Linux page tables and hardware page tables and inefficient use of memory
for page tables.

I think OSes like FreeBSD which don't have a concept of machine independent
page table are essentially free to do anything in the hat layer and thus 
have more flexibility.

On Linux/IA-64, such duplication is avoided by having a 3 level page
table and overloading the L3 page table with the hardware page table
functionality. In a nutshell, all L3 page tables are mapped in a region
in the *virtual* address space, such that to get the vtop translation
for address P, you can just index into this "linear" virtual page
table. Because the page table is in *virtual* address space, recursive
faults are possible. A significant chunk of the virtual address space
has to be reserved for this sparse, linear page table.

The other alternative is to use a global hash page table and walk the
collision chains in software. The advantage of this scheme is savings
in terms of both physical memory and virtual address space, but a 
heavier dependence on the hardware implemented hashing algorithm's
characteristics.

It isn't really clear which one is superior, but FreeBSD's VM architecture
allows a choice.

(c) Handling the register stack on system call entry and exit

Sparc has shown how frequent register stack flushing can 
offset the good effects of register stacks. IA-64 has some nice
tricks which can be used to avoid the flush.

(d) Restarting of system calls and interactions with the register stack

Linux does this by using a gcc directive which was created for this
purpose. The normal calling conventions allow input registers to be
treated as scratch. But under this directive they will be preserved,
so that system calls can be restarted.

The disadvantage of this approach is compiler specific code (which Linux
has not been averse to in the past) and some register allocation 
inefficiency in the kernel.

The alternate approach is to return ERESTART from the system call,
catch the error in libc and restart the system call with saved args.

Other general notes:

- Writing assembly code is tricky and writing efficient assembly code
  is trickier
- Lots of architectural state to keep track of
- Implementing setjmp and longjmp is tricky, because of the interaction
  with the register stack
- Errata, lack of support can be worked around by looking at Linux sources
  
I'd love to have technical discussions about the IA-64 architecture
from an OS perspective, if anyone on this list is interested. 

Since last September, I've moved on to a new daytime job, which has
nothing to do with operating systems or kernels. I have a limited amount
of spare time and I'm willing to help out with a IA-64 port, if the 
FreeBSD project decides to pursue it.

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Matthew Dillon]

:...
:and Linux essentially treats hardware page tables as TLBs.
:
:The problem with the above approach is duplication of information between
:Linux page tables and hardware page tables and inefficient use of memory
:for page tables.
:
:I think OSes like FreeBSD which don't have a concept of machine independent
:page table are essentially free to do anything in the hat layer and thus 
:have more flexibility.

If I understand the hardware hash table method correctly, then
I think the absolute best choice for FreeBSD is to use that method
as it will allow us to get rid of the scaleability problems we have
with the pv_entry_t scheme we use for IA32.  The number of pv_entry_t's
in an IA64 architecture wind up being fixed.  How big can we make the 
hardware-assisted hash table?

Also, a hash table scheme is a much better fit for a 64 bit address
space model, especially with sparse mappings.  The MIPS R4K and later
all use a hash table scheme and it seems to work well for them.

:I'd love to have technical discussions about the IA-64 architecture
:from an OS perspective, if anyone on this list is interested. 
:
:Since last September, I've moved on to a new daytime job, which has
:nothing to do with operating systems or kernels. I have a limited amount
:of spare time and I'm willing to help out with a IA-64 port, if the 
:FreeBSD project decides to pursue it.
:
:   -Arun
:
-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> > You're being just plain silly.  It takes about 5 minutes with the
> > manuals to realize just how little AXP and IA-64 have in common: one
> > is a classic superscalar out-of-order design, the other is just about
> > the opposite: a typical explicit-ILP architecture. What makes IA-64
> > great is the 8 years of statistical analysis of real-life software the
> > architecture design team spent fine-tuning the instruction set. What
> > makes AXP great is the clock rates Digital/Compaq manages to pump into
> > the beasts ;)
> 
> What makes IA-64 great is the fact that it has not been deployed, so
> Intel can say whatever it pleases them.
> 
> If you got REAL LIFE NUMBERS, based on REAL LIFE PERFORMANCE, then we
> can talk. Let's see how it does Quake, then we can talk.

This is rapidly becoming a stupid flame war so in the interest of keeping the
list on-topic, I won't be replying publically to this thread from now on. ;)

I *do* have some performance figures, as Intel has had the silicon for over
six months now, but, of course, Intel being Intel, their lawyers keep
everything under a wrap for now.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Arun Sharma]

On Fri, Feb 18, 2000 at 04:06:55PM -0800, Matthew Dillon wrote:
> If I understand the hardware hash table method correctly, then
> I think the absolute best choice for FreeBSD is to use that method
> as it will allow us to get rid of the scaleability problems we have
> with the pv_entry_t scheme we use for IA32.  The number of pv_entry_t's
> in an IA64 architecture wind up being fixed.  How big can we make the 
> hardware-assisted hash table?

Smaller than 2**64. Minimum is 2**15.

> 
> Also, a hash table scheme is a much better fit for a 64 bit address
> space model, especially with sparse mappings.  The MIPS R4K and later
> all use a hash table scheme and it seems to work well for them.
> 

Madhu Talluri's paper on page tables for 64 bit address spaces claims that
having collision chains is expensive - for 8 bytes of mapping information,
the pointer and tag storage overhead is 16 bytes.

Though page table space is important, in the age of big memory computers,
I think performance and manageability are more important.

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> :...
> :and Linux essentially treats hardware page tables as TLBs.
> :
> :The problem with the above approach is duplication of information between
> :Linux page tables and hardware page tables and inefficient use of memory
> :for page tables.
> :
> :I think OSes like FreeBSD which don't have a concept of machine independent
> :page table are essentially free to do anything in the hat layer and thus 
> :have more flexibility.
> 
> If I understand the hardware hash table method correctly, then
> I think the absolute best choice for FreeBSD is to use that method
> as it will allow us to get rid of the scaleability problems we have
> with the pv_entry_t scheme we use for IA32.  The number of pv_entry_t's
> in an IA64 architecture wind up being fixed.  How big can we make the 
> hardware-assisted hash table?
> 
> Also, a hash table scheme is a much better fit for a 64 bit address
> space model, especially with sparse mappings.  The MIPS R4K and later
> all use a hash table scheme and it seems to work well for them.

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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Arun Sharma]

On Sat, 19 Feb 2000 12:10:14 +1100, Patryk Zadarnowski
<[EMAIL PROTECTED]> wrote:

> 
> 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

Thanks for the great pointer. IA-64 short format = Linear virtual
arrays described in this paper. Long format = conventional hashed page
table.

Page 116 on LVAs in the paper talks about the disadvantages of using
the short format:

(a) Increased TLB misses
(b) Memory overhead similar to multilevel page tables

I don't know if clustered page tables can be implemented with the hardware
support present in IA-64. More investigation is needed.

> Maybe that way we can somehow make use of the Itanium's 4GB page size ;

The best thing is the abilitity to have large pinned TLB entries - they're
called TRs (translation registers) in the manuals. Linux for example
maps all of kernel memory with one huge TR. This also accomplishes the
traditional Linux way of mapping all of physical memory into kernel
virtual.

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Matthew Dillon]

:Madhu Talluri's paper on page tables for 64 bit address spaces claims that
:having collision chains is expensive - for 8 bytes of mapping information,
:the pointer and tag storage overhead is 16 bytes.
:
:Though page table space is important, in the age of big memory computers,
:I think performance and manageability are more important.
:
:   -Arun

I wasn't thinking of having collision chains, at least not long ones.
But I see what you mean.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Matthew Dillon]

: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.

I read Kevin's thesis.  Facinating!  The GPT concept is essentially
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
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.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> :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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Arun Sharma]

On Sun, Feb 20, 2000 at 12:42:14PM +1100, Patryk Zadarnowski wrote:
> 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.)

It looks like the hardware has to implement GPTs and know how to
walk them. How can FreeBSD use them without hardware support ?

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> On Sun, Feb 20, 2000 at 12:42:14PM +1100, Patryk Zadarnowski wrote:
> > 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.)
> 
> 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: the
only reason why IA-64 walks VPHT in hardware *at all* is to minimize the
impact on the pipeline and improve ILP: remember that the IA-64 hardware walk
is *advisory* -- that is, the OS still must supply software TLB refill
handlers, even if it uses a linear page table. Specifically, even though the
simulator may not display that behaviour, Itanium aborts the VPHT walk early
in quite a few cornel cases, even if completing the walk would avoid a TLB
miss.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Arun Sharma]

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 
your proposal is - use VHPT as a large in memory TLB and use GPT as operating
system's primary page table.

Doesn't that involve duplication of information in memory, especially if
the hash table is big ?

> 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.

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Matthew Dillon]

: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?

Linux uses a 'machine-independant' two or three level page table which
is then 'translated' to a machine dependant version.  However, for IA32
and any architecture that supports it, they attempt to overlay the
machine dependant and machine independant versions so they wind up
having only one page table.  This pretty much locks linux into a 
standard hierarchical page table design at least insofar as minimizing
memory overhead goes.  They can eat it support other architectures, but
it doesn't allow them to get rid of the machine independant version of
the page table.

Linux also stores persistent information in their machine independant
page tables.  They aren't throw-away like FreeBSD's are.  This will give
us a huge advantage when we do the IA64 port.

:> 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

In general I like the idea of using a VHPT as an STLB (are we having
fun with terminology yet?).  It should be possible to do even better 
by optimizing the TLB entries into variable-length pages.  We would
have to rewrite the page allocation code to make it practical, but it
could be done.  Many of the pages we are talking about here are from
shared libraries which generally wind up staying permantly resident
in memory anyway, which means that the overhead of making them
physically contiguous over time is low.  This makes the optimization
possible.

What I would truely love to do would be to get away with not using a GPT
at all and instead doing a vm_map_lookup_entry()/vm_page_lookup()
(essentially taking a vm_fault), then optimize the vm_map_entry 
structural hierarchy to look more like a GPT rather then the linear 
list it currently is.  When coupled with an STLB, especially one that 
can be optimized, I think performance would be extremely good.

: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.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Arun Sharma]

On Sun, Feb 20, 2000 at 04:28:51PM +1100, Patryk Zadarnowski wrote:
> > 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.

The TLB (VHPT in the case of IA-64) can be made large to reduce the
misses. Also, in the case of a VHPT miss, the software hander need 
not be any more expensive than it would have been in the absence of
the VHPT.

> 
> 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).
> 

That's true only for the short format. Not for the long format.

> 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?

No. L3 page tables are mapped into the linear page table. So the hardware
walker just walks Linux L3 page tables.

> before.)  Besides, the amount of space saved due to a smarter page table data
> structure more than compensates for the additional memory anyway.

Agree.

> > 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?

I can't get the data on IBM's 64 bit Power3. But on 32 bit architectures,
they use a hardware page walker. Researching more, I found someone who
agrees with you about smart software page tables being better than
hardware table walkers.

http://hq.fsmlabs.com/~cort/papers/linuxppc-mm/html/

But I have a hard time beliving that processor architects at major companies
are stupid in wasting transistors on hardware table walkers ;)

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Doug Rabson]

On Sun, 20 Feb 2000, Patryk Zadarnowski wrote:

> > On Sun, Feb 20, 2000 at 12:42:14PM +1100, Patryk Zadarnowski wrote:
> > > 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.)
> > 
> > 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.

So you have custom PALcode for Alpha on SASOS? We have been able to use
OSF1 PALcode up to now which makes life a lot easier for supporting new
hardware.

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> On Sun, 20 Feb 2000, Patryk Zadarnowski wrote:
> 
> > > On Sun, Feb 20, 2000 at 12:42:14PM +1100, Patryk Zadarnowski wrote:
> > > > 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.)
> > > 
> > > 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.
> 
> So you have custom PALcode for Alpha on SASOS? We have been able to use
> OSF1 PALcode up to now which makes life a lot easier for supporting new
> hardware.

Sure. Mungi (our SASOS) runs on top of an L4 microkernel. If anything,
it improves portability: porting Mungi from MIPS to Alpha took
literally few hours of working out endianess-related bugs ;) (tell me
the same about FreeBSD ;P Of course using OSF1 PALcode simplifies life
for FreeBSD, but it's really not an option for our OS research.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Arun Sharma]

Matt Dillon wrote:
> 
> Linux also stores persistent information in their machine independant
> page tables.  They aren't throw-away like FreeBSD's are.  This will give
> us a huge advantage when we do the IA64 port.

I forgot to mention that Linux/IA-64 switches the processor to physical mode 
to walk the 3 level page table in the VHPT miss handler. This has additional
overheads associated.

> In general I like the idea of using a VHPT as an STLB (are we having
> fun with terminology yet?).

Yes, Software TLB is a misnomer. Second level TLB is probably better. VHPT
can behave as either STLB or the primary page table of the OS.

> What I would truely love to do would be to get away with not using a GPT
> at all and instead doing a vm_map_lookup_entry()/vm_page_lookup()
> (essentially taking a vm_fault), then optimize the vm_map_entry 
> structural hierarchy to look more like a GPT rather then the linear 
> list it currently is.  When coupled with an STLB, especially one that 
> can be optimized, I think performance would be extremely good.

For finding the vm_map_entry for a virtual address, a balanced binary tree 
works better. Linux does well here - it uses AVL trees, which find the
right vm_map_entry in O(log n) time.

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Jamie Bowden]

On Fri, 18 Feb 2000, Jordan K. Hubbard wrote:

:> If you got REAL LIFE NUMBERS, based on REAL LIFE PERFORMANCE, then we
:> can talk. Let's see how it does Quake, then we can talk.
:
:Alpha does quake? :-)

Not that I know of, but MIPS/SGI does.  (hint hint)

Jamie Bowden

-- 

"Of course, that's sort of like asking how other than Marketing, 
Microsoft is different from any other software company..."
Kenneth G. Cavness



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message