Re: The kernel swap daemon (2.0.*) question

Stephen C. Tweedie (sct@dcs.ed.ac.uk)
Sun, 22 Feb 1998 00:51:29 GMT


Hi Dave,

On Sat, 21 Feb 1998 15:14:33 +0000 (Local Time Zone Unknown),
rusling@linux.reo.dec.com said:

> All,
> could anyone shed light on the order in which the swap
> daemon tries to free up pages when the system starts to run out
> of physical memory? It tries to free pages in the following order:

> (1) reducing the size of the page and buffer caches
> (2) swapping out shared pages
> (3) swapping out dirty pages, discarding clean pages

Yep...

> I can see why it tries (1) first, it's relatively easy to
> do but I don't see why it tries (2) next. Note that the code
> remembers which "state" that it's in and so it will start freeing
> using the last successful method. I would have thought that freeing
> shared pages (shared via IPC or via sharing images/libraries) would
> affect many processes and the swapped out pages would be fairly
> likely to be needed again. (3) only "hurts" one process at a time,
> (2) "hurts" lots. Any clues would be useful.

First of all, (2) only deals with SysV shared memory pages. Shared
images and libraries are all done under (3).

Both (2) and (3) use a similar mechanism, which involves traversing the
page tables of each process and performing reference counting to
determine when a page is or is not in use. Only once the reference
count goes to zero for a SysV shared-memory page will it be swapped
out. Likewise, in the swap-out code, if a page is shared (for example,
we have a shared memory mapped file such as libc.so), then only once the
page's refcount falls to zero can the page be physically evicted from
memory.

So, the handling of sharing is performed in the same way for both (2)
and (3). Every single reference to a page has equal weight, so shared
pages automatically get extra protection against being swapped out ---
we have to wait until every process referencing that page has "voted" to
swap out a shared page before we can free the memory.

> Whilst I am at it. Why does it always "remember" the last
> successful method? Shouldn't that be dependent on how agressively it
> is swapping, say by looking at free_pages_low and free_pages_high?

It's just a way of making sure we are most aggressive at pruning back
pages from the source which is currently the most under-utilised. Once
it starts to become harder to get free pages from that source, we'll
automatically fall back to another source.

Cheers,
Stephen.

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