Christoph Lameter wrote:
On Mon, 22 Jan 2007, Rik van Riel wrote:
The big one is how we are to do some background aging in a
clock-pro system, so referenced bits don't just pile up when
the VM has enough memory - otherwise we might not know the
right pages to evict when a new process starts up and starts
allocating lots of memory.
There are two bad choices right?
1. Scan for reference bits
Bad because we may have to scan quite a bit without too much
result. LRU allows us to defer this until memory is tight.
Any such scan will pollute the cache and cause a stall of
the app. You really do not want this for a realtime system.
2. Take faults on reference and update the page state.
Bad because this means a fault if the reference bit
has not been set. Could be many faults.
Clock pro really requires 2 right? So lots of additional page faults?
Nope, the faults are not required.
I suspect you're confused with the part where it keeps track
of recently evicted (not resident in RAM at all) pages. That
kind of info is common in database replacement schemes, but
not in general purpose OS memory management.
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
