From: Jason Gunthorpe <jgg@ziepe.ca>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Yu Zhao <yuzhao@google.com>, Andy Lutomirski <luto@kernel.org>,
Peter Xu <peterx@redhat.com>, Pavel Emelyanov <xemul@openvz.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
Minchan Kim <minchan@kernel.org>, Will Deacon <will@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Hugh Dickins <hughd@google.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Matthew Wilcox <willy@infradead.org>,
Oleg Nesterov <oleg@redhat.com>, Jann Horn <jannh@google.com>,
Kees Cook <keescook@chromium.org>,
John Hubbard <jhubbard@nvidia.com>,
Leon Romanovsky <leonro@nvidia.com>, Jan Kara <jack@suse.cz>,
Kirill Tkhai <ktkhai@virtuozzo.com>,
Nadav Amit <nadav.amit@gmail.com>, Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse
Date: Mon, 11 Jan 2021 11:52:45 -0400 [thread overview]
Message-ID: <20210111155245.GM504133@ziepe.ca> (raw)
In-Reply-To: <X/prosulFrEoNnoF@redhat.com>
On Sat, Jan 09, 2021 at 09:51:14PM -0500, Andrea Arcangeli wrote:
> Are we spending 32bit in mm_struct atomic_t just to call atomic_set(1)
> on it? Why isn't it a MMF_HAS_PINNED that already can be set
> atomically under mmap_read_lock too? There's bit left free there, we
> didn't run out yet to justify wasting another 31 bits. I hope I'm
> overlooking something.
It needs to be atomic because it is set under gup fast, no mmap
lock. Peter and myself did not find another place to put this that was
already atomic
> The existence of FOLL_LONGTERM is good and makes a difference at times
> for writeback if it's on a MAP_SHARED, or it makes difference during
> GUP to do a page_migrate before taking the pin, but for the whole rest
> of the VM it's irrelevant if it's long or short term, so I'm also
> concerned from what Jason mentioned about long term pins being treated
> differently within the VM.
Why? They are different. write protect doesn't stop modification of
the data. How is that not a relavent and real difference?
Jason
next prev parent reply other threads:[~2021-01-11 15:52 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-10 0:44 Andrea Arcangeli
2021-01-10 0:44 ` [PATCH 1/1] " Andrea Arcangeli
2021-01-10 2:54 ` Andrea Arcangeli
2021-01-11 14:11 ` Kirill A. Shutemov
2021-01-10 0:55 ` [PATCH 0/1] " Linus Torvalds
2021-01-10 1:19 ` Linus Torvalds
2021-01-10 1:37 ` Linus Torvalds
2021-01-10 3:24 ` Andrea Arcangeli
2021-01-10 2:51 ` Andrea Arcangeli
2021-01-10 3:51 ` Linus Torvalds
2021-01-10 19:30 ` Linus Torvalds
2021-01-11 1:18 ` Jason Gunthorpe
2021-01-11 7:26 ` John Hubbard
2021-01-11 12:42 ` Matthew Wilcox
2021-01-11 16:05 ` Jason Gunthorpe
2021-01-11 16:15 ` Michal Hocko
2021-01-11 19:19 ` Linus Torvalds
2021-01-11 22:18 ` Linus Torvalds
2021-01-12 17:07 ` Andy Lutomirski
2021-01-12 23:51 ` Jerome Glisse
2021-01-13 2:16 ` Matthew Wilcox
2021-01-13 2:43 ` Linus Torvalds
2021-01-13 3:31 ` Linus Torvalds
2021-01-13 8:52 ` David Hildenbrand
2021-01-13 8:57 ` David Hildenbrand
2021-01-13 12:32 ` Kirill A. Shutemov
2021-01-13 12:55 ` Matthew Wilcox
2021-01-13 19:54 ` Linus Torvalds
2021-01-13 23:54 ` Peter Xu
2021-01-11 15:52 ` Jason Gunthorpe [this message]
2021-01-15 8:59 ` David Hildenbrand
2021-01-15 18:37 ` Jason Gunthorpe
2021-01-15 19:46 ` David Hildenbrand
2021-01-15 19:53 ` Jason Gunthorpe
2021-01-16 3:40 ` John Hubbard
2021-01-16 11:42 ` David Hildenbrand
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=20210111155245.GM504133@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=jhubbard@nvidia.com \
--cc=keescook@chromium.org \
--cc=kirill@shutemov.name \
--cc=ktkhai@virtuozzo.com \
--cc=leonro@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=minchan@kernel.org \
--cc=nadav.amit@gmail.com \
--cc=oleg@redhat.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=rppt@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=xemul@openvz.org \
--cc=yuzhao@google.com \
/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