Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Feb 2000 22:20:24 -0800
From:      Arun Sharma <adsharma@c62443-a.frmt1.sfba.home.com>
To:        dillon@apollo.backplane.com
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: 64bit OS? 
Message-ID:  <200002210620.WAA27921@c62443-a.frmt1.sfba.home.com>
In-Reply-To: <200002200653.WAA99167@apollo.backplane.com>
References:  <200002200528.QAA04257@mycenae.ilion.eu.org> <200002200653.WAA99167@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 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?200002210620.WAA27921>