Re: increasing page size

Re: increasing page size

[Rik van Riel]

On Sun, 5 Jul 1998, Peter-Paul Witta wrote:

> > Stephen Tweedie and Ingo Molnar have some swapin
> > readahead code, carefully hidden in a secret place...
> 
> this wont solve the dma fragmentation problem, would it???

That is solved with a new memory allocator. See my home
page for more info.

> > Page size is coded into hardware (except on m68k) and
> > there's no reason for using 32 kB pages when we can
> > use proper readahead and I/O clustering.
> 
> i thought intel ia32 had no problems with 4k .. 4m ???

x86 uses 4k for user pages. The 4M pages only work for
ring-0 (kernel mode) stuff.

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: increasing page size

[Rik van Riel]

On Sun, 5 Jul 1998, Gerard Roudier wrote:
> On Sun, 5 Jul 1998, Rik van Riel wrote:
> 
> > Even if files are fragmented, readahead _will_ give a large
> > performance increase. This is because we can bring in the
> 
> This requires:
> 
> 1 - The program will really need the next page.
> 2 - The latency to get the next page is far lower than the program 
>     time execution before it will need of the next page.
> 3 - The page is still in memory when the program will 
>     need it.

With good algorithms, the kernel can make some quite proper
decisions on which readahead can be done and which readahead
is too expensive...

I believe Ingo's readahead code (not yet released) does something
like this. It analizes the programs' usage pattern and swaps in
until the page that has 50% probability of usage. If the program
soft-faults one of the preread pages, the kernel reads in the next
one(s) and this goes on until the kernel frees one of the preread
pages.

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: increasing page size

[Rik van Riel]

On Sun, 5 Jul 1998 ralf@uni-koblenz.de wrote:
> On Sat, Jul 04, 1998 Rik van Riel wrote:
> 
> > Page size is coded into hardware (except on m68k) and
> > there's no reason for using 32 kB pages when we can
> > use proper readahead and I/O clustering.
> 
> Page size is selectable on a per page base on all MIPS CPUs.  Possible
> sizes are 4kb, 16kb, 64kb, 256kb, 1mb, 4mb and 16mb.  Since the number
> of TLB entries (64 on R3k family, 32 entries on R4300, 48 R4k, R5k)
> can become a performance limit for apps with a large working set, using
> larger pagesizes is desireable.

Hmm, would that be tunable on a per-application basis, or
maybe as a kernel compile time option?

(the per-application thingy would be nice so we could avoid
breakage of applications when we switch the page size of the
kernel)

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org