Mailing List Archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Re: Alan Cox's remark at Fosdem

(good Lord, you're prolific tonight)

On Thu, Mar 03, 2005 at 04:49:38PM +0900, Uva Coder wrote:

> currently the Linux camp is in a world of hurt because they don't have
> clarity.

With that statement in mind, what are your thoughts about this:

<begin quote from -- formatting is intact>

Christoph Lameter would like to get rid of the disconnect between in-kernel and hardware page tables; to that end, he has proposed a new abstraction layer which would handle access to the processor's memory management unit (MMU). With the new layer in place, there would be no more hierarchical page tables in the core kernel. If the hardware uses hierarchical tables, the architecture-specific code would still work with them, but they would be hidden from the core. The proposed replacement interface is somewhat vague at this stage, but some features have been sketched out:

    * A new type, mmu_entry_t would represent a translation from a virtual address to the corresponding physical address. It thus functions like a page table entry, but it could contain information not necessarily found in page table entries now, such as "large page" information and, possibly, statistics information.

    * A translation set (mmu_translation_set_t) represents the address space for a process; it is a collection of mmu_entry_t values and required housekeeping information.

    * The new interface would also implement transactions (mmu_transaction_t), so that complex changes to page tables could be performed in an atomic manner. The transaction abstraction hides the page table locking within the architecture-specific code, since that locking may be done in very different ways. 

Initially, the new interface would be implemented on top of the existing hierarchical page tables. The transition could thus be made a little smoother, and architectures which actually use the hierarchical tables could continue to function as always. Eventually, however, direct access to those tables from the core kernel code would be removed, and architectures with different ideas of how page tables should be managed would be able to drop the hierarchical tables.

Once the transition has been made, other things would become possible as well. The current memory management system is really only comfortable when pages are all the same size. The support for huge pages has been bolted on to the side, and it does not really hide the fact that different processors handle large pages in very different ways. The new scheme would present a simple mksize() function to change the size of a page, and would hide from the kernel the details of how that size change is actually done. In addition, the new scheme would allow for global pages which appear in every process's address space, and for keeping statistics of the various types of pages in the system. 

<end quote from>

Am I just old-fashioned, or are the VM guys smoking crack?  This makes, what,
the third VM rewrite in two years, right?

-- Chris
	GPG key FEB9DE7F (91AF 4534 4529 4BCC 31A5  938E 023E EEFB FEB9 DE7F)

Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links