On Sun, 4 Apr 1999 17:02:17 +0100 (BST), Mark Hemment <markhe@sco.COM>
said:
> Hi Stephen/All,
> I've been looking through Linux's memory management code for the first
> time in 12mths, seeing what has changed. A line in swapfile.c, in the
> func shrink_mmap(), looks suspicious. Not wrong, just not doing what is
> expected of it;
> ...
> After this, the page has a ref count of 2 (one for the remaining
> mapping, and one for the swap-cache entry). The swap_map count is
> 2. Say, before swap_out() finds the second mapping, shrink_mmap() finds
> the page.
No, we have already checked this: before shrink_mmap gets to the code
you refer to, we have already done a
/* We can't free pages unless there's just one user */
if (atomic_read(&page->count) != 1)
continue;
shrink_mmap() only deals with unshared, pure cache pages. Shared pages
are handled correctly by mm/vmscan.c.
> Also in do_wp_page(), what happens to a swap-cached page whose reference
> count is greater than 2? There looks like a missing default case which
> does a swap_free().
No, that is very much deliberate: there may well be other processes
around which still refer to the copy on disk, so we want to do a COW and
keep the swap cache copy present. (This catches the case of a
partially-swapped-out process which keeps forking: if one child swaps a
page in, then we do a COW and the next child to access that page will
find its copy already in cache.)
Every swap cache page counts as a reference against the cached swap
entry. delete_from_swap_cache performs a swap_free if necessary.
> Finally, shouldn't swap_free() only update p->lowest_bit and
> p->highest_bit when p->swap_map[offset] == 0?
Probably!
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/