No subject

Unknown Unknown
Sat Jul 14 17:41:06 PDT 2007

fc5cdc4k2df92b2d5c109dab at> <4699588C.6040005 at> <46995FB0.1080108 at> <46996887.10404 at> <200707150029.l6F0TQup002271 at>
From: "Simon 'corecode' Schubert" <corecode at>
Subject: Re: 4mb PAGES for mbuf clusters
Date: Sun, 15 Jul 2007 02:39:26 +0200
List-Post: <mailto:kernel at>
List-Subscribe: <mailto:kernel-request at>
List-Unsubscribe: <mailto:kernel-request at>
List-Help: <mailto:kernel-request at>
List-Owner: <mailto:owner-kernel at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
In-Reply-To: <200707150029.l6F0TQup002271 at>
Sender: kernel-errors at
Errors-To: kernel-errors at
Lines: 28
X-Trace: 1184460372 795
Xref: dragonfly.kernel:11255

Matthew Dillon wrote:
> :
> :Thomas E. Spanjaard wrote:
> :>>> Is not the large pages necessary for 64 GB memory support ?
> :>> no.  and PAE is stupid, so we won't do that.  it's really stupid.  
> :> Actually, we will do that. Perhaps not on x86-32, but it sure is a 
> :> requirement for 64bit long mode on x86-64...
> :what is?  PAE is not, just the 4-level page table.
>      Nothing wrong with the 4-level page table.  It's designed so you
>      can assign address spaces their own independant page table directories.
>      So, for example, the kernel would no longer need to stuff all the
>      kernel's PTEs into each user page table in order to keep the kernel
>      mapped.

yah, and you simply need it to address more than 4GB.

>      Besides, pretty much all the levels except the last are cached.

but they will be flushed on a task switch, right?  We should check out that GLOBAL PTE flag which prevents TLB entries to be flushed.


Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ��� NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |      Against  HTML   \
Dude 2c 2 the max   !       Mail + News   / \

More information about the Kernel mailing list