Re: Why active list and inactive list?

[Rik van Riel <riel@redhat.com>]

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.