linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Linux-MM <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Marty Mcfadden <mcfadden8@llnl.gov>,
	"Maya B . Gokhale" <gokhale2@llnl.gov>,
	Jann Horn <jannh@google.com>, Christoph Hellwig <hch@lst.de>,
	Oleg Nesterov <oleg@redhat.com>,
	Kirill Shutemov <kirill@shutemov.name>, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH v3] mm/gup: Allow real explicit breaking of COW
Date: Tue, 11 Aug 2020 17:42:55 -0400	[thread overview]
Message-ID: <20200811214255.GE6353@xz-x1> (raw)
In-Reply-To: <CAHk-=wifRg0pDhufQFasWa7G3sMHbG0nahnm5yRwvTKpKU9g4A@mail.gmail.com>

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@linux-foundation.org> 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


  reply	other threads:[~2020-08-11 21:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-11 18:39 [PATCH v3] mm/gup: Allow real explicit breaking of COW Peter Xu
2020-08-11 19:07 ` Jann Horn
2020-08-11 20:02   ` Peter Xu
2020-08-11 20:22     ` Jann Horn
2020-08-11 21:23       ` Peter Xu
2020-08-11 19:24 ` Linus Torvalds
2020-08-11 20:06   ` Linus Torvalds
2020-08-11 20:46     ` Linus Torvalds
2020-08-11 21:42       ` Peter Xu [this message]
2020-08-11 23:10         ` Linus Torvalds
2020-08-20 21:54           ` Peter Xu
2020-08-20 22:01             ` Linus Torvalds
2020-08-21 10:13               ` Jan Kara
2020-08-21 12:27                 ` Linus Torvalds
2020-08-21 15:47                   ` Jan Kara
2020-08-21 17:00                     ` Linus Torvalds
2020-08-21 18:08                       ` Peter Xu
2020-08-21 18:23                         ` Linus Torvalds
2020-08-21 19:05                           ` Linus Torvalds
2020-08-21 19:06                             ` Linus Torvalds
2020-08-21 19:31                           ` Peter Xu
2020-08-21 19:42                             ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200811214255.GE6353@xz-x1 \
    --to=peterx@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=gokhale2@llnl.gov \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcfadden8@llnl.gov \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).