Hi,
On Wed, May 02, 2001 at 12:54:15PM +0200, Rogier Wolff wrote:
>
> first: Thanks for clearing this up for me.
>
> So, there are in fact some more "states" a swap-page can be in:
>
> -(0) free
> -(1) allocated, not in mem.
> -(2) on swap, valid copy of memory.
> -(3) on swap: invalid copy, allocated for fragmentation, can
> be freed on demand if we are close to running out of swap.
>
> If we running low on (0) swap-pages we can first start to reap the (3)
> pages, and if that runs out, we can start reaping the (2)
> pages. Right?
Yes. However, there is other state to worry about too. Anonymous
pages are referenced from process page tables. As long as the page
tables are referring to the copy in memory, you can free up the copy
on disk. However, if any ptes point to the copy on disk, you cannot
(and remember, process forks can result in multiple process mm's
pointing to the same anonymous page, and some of those mm's may point
to swap while others point to the in-core page).
So the aim is more complex. Basically, once we are short on VM, we
want to eliminate redundant copies of swap data. That implies two
possible actions, not one --- we can either remove the swap page for
data which is already in memory, or we can remove the in-memory copy
of data which is already on swap. Which one is appropriate will
depend on whether the ptes in the system point to the swap entry or
the memory entry. If we have ptes pointing to both, then we cannot
free either.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 07 2001 - 21:00:12 EST