Re: large page patch

From: Andrew Morton (
Date: Thu Aug 01 2002 - 20:26:40 EST

"David S. Miller" wrote:
> From: Andrew Morton <>
> Date: Thu, 01 Aug 2002 17:37:46 -0700
> Some observations which have been made thus far:
> - Minimal impact on the VM and MM layers
> Well the downside of this is that it means it isn't transparent
> to userspace. For example, specfp2000 results aren't going to
> improve after installing these changes. Some of the other large
> page implementations would.
> - The change to MAX_ORDER is unneeded
> This is probably done to increase the likelyhood that 4MB page orders
> are available. If we collapse 4MB pages deeper, they are less likely
> to be broken up because smaller orders would be selected first.

This is leakage from ia64, which supports up to 256k pages.

> Maybe it doesn't make a difference....
> - swapping of large pages and making them pagecache-coherent is
> unpopular.
> Swapping them is easy, any time you hit a large PTE you unlarge it.
> This is what some of other large page implementations do. Basically
> the implementation is that set_pte() breaks apart large ptes when
> necessary.

As far as mm/*.c is concerned, there is no pte. It's just a vma
which is marked "don't touch" These pages aren't on the LRU, nothing
knows about them.

Apparently a page-table based representation could not be used by PPC.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:17 EST