From: David Hildenbrand <david@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
liubo <liubo254@huawei.com>, Matthew Wilcox <willy@infradead.org>,
Hugh Dickins <hughd@google.com>, Jason Gunthorpe <jgg@ziepe.ca>,
John Hubbard <jhubbard@nvidia.com>
Subject: Re: [PATCH v1 0/4] smaps / mm/gup: fix gup_can_follow_protnone fallout
Date: Fri, 28 Jul 2023 23:31:49 +0200 [thread overview]
Message-ID: <22262495-c92c-20fa-dddf-eee4ce635b12@redhat.com> (raw)
In-Reply-To: <ZMQxNzDcYTQRjWNh@x1n>
On 28.07.23 23:20, Peter Xu wrote:
> On Fri, Jul 28, 2023 at 11:02:46PM +0200, David Hildenbrand wrote:
>> Can we get a simple revert in first (without that FOLL_FORCE special casing
>> and ideally with a better name) to handle stable backports, and I'll
>> follow-up with more documentation and letting GUP callers pass in that flag
>> instead?
>>
>> That would help a lot. Then we also have more time to let that "move it to
>> GUP callers" mature a bit in -next, to see if we find any surprises?
>
> As I raised my concern over the other thread, I still worry numa users can
> be affected by this change. After all, numa isn't so uncommon to me, at
> least fedora / rhel as CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y. I highly
> suspect that's also true to major distros. Meanwhile all kernel modules
> use gup..
>
> I'd say we can go ahead and try if we want, but I really don't know why
> that helps in any form to move it to the callers.. with the risk of
> breaking someone.
>
Indeed, that's why I suggest to be a bit careful, especially with stable.
> Logically it should also be always better to migrate earlier than later,
> not only because the page will be local earlier, but also per I discussed
> also in the other thread (that the gup can hold a ref to the page, and it
> could potentially stop numa balancing to succeed later).
I get your point, but I also see the following cases (QEMU/KVM as example):
* User space triggers O_DIRECT. It will be short-lived. But is it really
an access from that CPU (NUMA node) to that page? At least for KVM,
you much rather want to let KVM trigger the NUMA fault on actual
memory access from a guest VCPU, not from a QEMU iothread when pinning
the page?
* vfio triggers FOLL_PIN|FOLL_LONGTERM from a random QEMU thread.
Where should we migrate that page to? Would it actually be counter-
productive to migrate it to the NUMA node of the setup thread? The
longterm pin will turn the page unmovable, yes, but where to migrate
it to?
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2023-07-28 21:32 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-27 21:28 David Hildenbrand
2023-07-27 21:28 ` [PATCH v1 2/4] mm/gup: Make follow_page() succeed again on PROT_NONE PTEs/PMDs David Hildenbrand
2023-07-28 2:30 ` John Hubbard
2023-07-28 9:08 ` David Hildenbrand
2023-07-28 10:12 ` David Hildenbrand
2023-07-27 21:28 ` [PATCH v1 3/4] smaps: use vm_normal_page_pmd() instead of follow_trans_huge_pmd() David Hildenbrand
2023-07-27 21:28 ` [PATCH v1 4/4] mm/gup: document FOLL_FORCE behavior David Hildenbrand
2023-07-28 16:18 ` [PATCH v1 0/4] smaps / mm/gup: fix gup_can_follow_protnone fallout Linus Torvalds
2023-07-28 17:30 ` David Hildenbrand
2023-07-28 17:54 ` David Hildenbrand
2023-07-28 19:40 ` David Hildenbrand
2023-07-28 19:50 ` Peter Xu
2023-07-28 20:00 ` David Hildenbrand
2023-08-02 10:24 ` Mel Gorman
2023-07-28 19:39 ` Peter Xu
2023-07-28 19:52 ` David Hildenbrand
2023-07-28 20:23 ` Linus Torvalds
2023-07-28 20:33 ` David Hildenbrand
2023-07-28 20:50 ` Linus Torvalds
2023-07-28 21:02 ` David Hildenbrand
2023-07-28 21:20 ` Peter Xu
2023-07-28 21:31 ` David Hildenbrand [this message]
2023-07-28 22:14 ` Jason Gunthorpe
2023-07-31 16:01 ` Peter Xu
2023-07-28 21:32 ` John Hubbard
2023-07-28 21:49 ` Peter Xu
2023-07-28 22:00 ` John Hubbard
2023-07-31 16:05 ` Peter Xu
[not found] ` <412bb30f-0417-802c-3fc4-a4e9d5891c5d@redhat.com>
2023-07-29 9:35 ` David Hildenbrand
2023-07-31 16:10 ` Peter Xu
2023-07-31 16:20 ` David Hildenbrand
2023-07-31 18:23 ` Linus Torvalds
2023-07-31 18:51 ` Peter Xu
2023-07-31 19:00 ` David Hildenbrand
2023-07-31 19:07 ` Linus Torvalds
2023-07-31 19:22 ` David Hildenbrand
2023-08-01 13:05 ` Jason Gunthorpe
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=22262495-c92c-20fa-dddf-eee4ce635b12@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liubo254@huawei.com \
--cc=peterx@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.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