Re: increasing page size

Iain McClatchie (iainmcc@ix.netcom.com)
Tue, 07 Jul 1998 01:30:50 -0400


Alan> o Per CPU "hot" page lists
Alan> o Page colouring

Stephen> It's not really anything that is going to get in the way
Stephen> of zoned allocation: the two principles are orthogonal.
Stephen> If we are zoning in blocks of 32k or larger, then the
Stephen> zoning itself is not telling us anything about smaller
Stephen> units than that. Page colouring and CPU hot lists work
Stephen> best at the smallest granularity available, i.e. on a
Stephen> per-page basis.

Aren't per-cpu hot lists almost directly in conflict with an LRU
physical page reuse policy? It seems that LRU policy is essential
if we want to make forget-behind work.

I imagine a per-cpu hot list and aggressive forget-behind conspiring
so that the kernel unmaps pages right after the program touches
them, then reallocates those pages immediately, which causes the
program to suffer a major fault when it goes back to touch the data.

I personally like the semantics of read() much better than mmap()
since the program is essentially telling the kernel that the data
currently in the buffer is scrap. Any whole pages in the buffer
can be unmapped and immediately reused for other purposes, without
the need for heuristics in the kernel.

It could even be a performance win to remap the read() buffer to
a cache-cold page when it will be the target of the disk read,
because a cold page doesn't have to be intervened or invalidated
from the L2 cache. Those interventions and invalidates take L2 tag
cycles even if they're handled by the hardware... but maybe that
effect is swamped by the time for the extra page table activity.

-Iain McClatchie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu