Re: [RFC] Changing COW detection to be memory hotplug friendly

[Hugh Dickins <hugh@veritas.com>]

On Fri, 11 Feb 2005, Andrea Arcangeli wrote:
> 
> Ok, I'm quite convinced it's correct now. The only thing that can make
> mapcount go up without the lock on the page without userspace
> intervention (and userspace intervention would make it an undefined
> behaviour like in my example with fork), was the swapin, and you covered
> it by moving the unlock after page_add_anon_rmap (so mapcount changes
> atomically with the page_swapcount there too). Swapoff was already doing
> it under the page lock.

Thanks a lot for thinking it through, yes, that's how it is.

(For a while I felt nervous about moving that unlock_page below
the arch-defined flush_icache_page; but then realized that since it's
already done with page_table spinlock, PG_locked cannot be an issue.)

> Then we should use the mapcount/swapcount in remove_exclusive_swap_page
> too.

Originally I thought so, but later wasn't so sure.  There might be
somewhere which stabilizes PageSwapCache by incrementing page_count,
rechecks it, waits to get lock_page, then assumes still PageSwapCache?
(Though it's hard to see why it would need to make such an assumption,
and in the equivalent file case would have to allow for truncation.)

It just needs a wider audit than the simpler can_share_swap_page case,
and can be done independently later on.

By the way, while we're talking of remove_exclusive_swap_page:
a more functional issue I sometimes wonder about, why don't we
remove_exclusive_swap_page on write fault?  Keeping the swap slot
is valuable if read fault, but once the page is dirtied, wouldn't
it usually be better to free that slot and allocate another later?

But I'm always scared of making such changes to swapping, because
I cannot imagine a good enough range of swap performance tests.

Hugh