Re: [PATCH v3] mm/gup: Allow real explicit breaking of COW

[Peter Xu]

On Tue, Aug 11, 2020 at 01:46:05PM -0700, Linus Torvalds wrote:
> On Tue, Aug 11, 2020 at 1:06 PM Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Maybe trying to reuse the page just isn't worth it?
> 
> Well, the attached patch boots, and hasn't slowed kernel compiles
> down. But it may do horrible things due to leaving swap cache pages
> and KSM pages to be reaped by the memory scanner, instead of being
> reused.
> 
> I wouldn't notice, I have too much memory in this machine anyway.
> 
> It might have positive side effects too, of course. Not waiting for
> the page lock in the page fault case could be a big win on some loads.
> We do_wp_page() was one of the paths to the page lock that caused the
> nasty latency spikes (I'm not sure it was a dominant one, but it was
> up there).
> 
> So maybe it is worth running some test loads on. And while this patch
> doesn't do it, applying this should mean that you can just revert all
> the COW games entirely, and we can remove the should_force_cow_break()
> from the GUP paths.
> 
> (Also - if this actually works, we can get rid of reuse_ksm_page(),
> this was the only user)

I don't know good enough on the reuse refactoring patch (which at least looks
functionally correct), but... IMHO we still need the enforced cow logic no
matter we refactor the page reuse logic or not, am I right?

Example:

  - Process A & B shares private anonymous page P0

  - Process A does READ of get_user_pages() on page P0

  - Process A (e.g., another thread of process A, or as long as process A still
    holds the page P0 somehow) writes to page P0 which triggers cow, so for
    process A the page P0 is replaced by P1 with identical content

Then process A still keeps the reference to page P0 that potentially belongs to
process B or others?

Thanks,

-- 
Peter Xu