linux-kernel - Re: Why active list and inactive list?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Jan 2007 01:39:39 +0100
From:	Andrea Arcangeli <andrea@...e.de>
To:	Niki Hammler <mailinglists@...aq.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Why active list and inactive list?

On Tue, Jan 23, 2007 at 01:10:46AM +0100, Niki Hammler wrote:
> Dear Linux Developers/Enthusiasts,
> 
> For a course at my university I'm implementing parts of an operating
> system where I get most ideas from the Linux Kernel (which I like very
> much). One book I gain information from is [1].
> 
> Linux uses for its Page Replacing Algorithm (based on LRU) *two* chained
> lists - one active list and one active list.
> I implemented my PRA this way too.
> 
> No the big question is: WHY do I need *two* lists? Isn't it just
> overhead/more work? Are there any reasons for that?
>
> In my opinion, it would be better to have just one just; pop frames to
> be swapped out from the end of the list and push new frames in front of
> it. Then just evaluate the frames and shift them around in the list.
> 
> Is there any explanation why Linux uses two lists?

Back then I designed it with two lru lists because by splitting the
active from the inactive cache allows to detect the cache pollution
before it starts discarding the working set. The idea is that the
pollution will enter and exit the inactive list without ever being
elected to the active list because by definition it will never
generate a cache hit. The working set will instead trigger cache hits
during page faults or repeated reads, and it will be preserved better
by electing it to enter the active list.

A page in the inactive list will be collected much more quickly than a
page in the active list, so the pollution will be collected more
quickly than the working set. Then the VM while freeing cache tries to
keep a balance between the size of the two lists to avoid being too
unfair, obviously at some point the active list have to be
de-activated too. If your server "fits in ram" you'll find lots of
cache to be active and so the I/O activity not part of the working set
will be collected without affecting the working set much.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/