From: Jason Gunthorpe <jgg@nvidia.com>
To: David Hildenbrand <david@redhat.com>
Cc: Alistair Popple <apopple@nvidia.com>,
Felix Kuehling <felix.kuehling@amd.com>,
Alex Sierra <alex.sierra@amd.com>,
linux-mm@kvack.org, rcampbell@nvidia.com,
linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
hch@lst.de, jglisse@redhat.com, willy@infradead.org,
akpm@linux-foundation.org
Subject: Re: [PATCH v1 1/3] mm: split vm_normal_pages for LRU and non-LRU handling
Date: Thu, 17 Mar 2022 10:25:43 -0300 [thread overview]
Message-ID: <20220317132543.GW11336@nvidia.com> (raw)
In-Reply-To: <ab26f7a0-728e-9627-796b-e8e850402aae@redhat.com>
On Thu, Mar 17, 2022 at 09:13:50AM +0100, David Hildenbrand wrote:
> On 17.03.22 03:54, Alistair Popple wrote:
> > Felix Kuehling <felix.kuehling@amd.com> writes:
> >
> >> On 2022-03-11 04:16, David Hildenbrand wrote:
> >>> On 10.03.22 18:26, Alex Sierra wrote:
> >>>> DEVICE_COHERENT pages introduce a subtle distinction in the way
> >>>> "normal" pages can be used by various callers throughout the kernel.
> >>>> They behave like normal pages for purposes of mapping in CPU page
> >>>> tables, and for COW. But they do not support LRU lists, NUMA
> >>>> migration or THP. Therefore we split vm_normal_page into two
> >>>> functions vm_normal_any_page and vm_normal_lru_page. The latter will
> >>>> only return pages that can be put on an LRU list and that support
> >>>> NUMA migration, KSM and THP.
> >>>>
> >>>> We also introduced a FOLL_LRU flag that adds the same behaviour to
> >>>> follow_page and related APIs, to allow callers to specify that they
> >>>> expect to put pages on an LRU list.
> >>>>
> >>> I still don't see the need for s/vm_normal_page/vm_normal_any_page/. And
> >>> as this patch is dominated by that change, I'd suggest (again) to just
> >>> drop it as I don't see any value of that renaming. No specifier implies any.
> >>
> >> OK. If nobody objects, we can adopts that naming convention.
> >
> > I'd prefer we avoid the churn too, but I don't think we should make
> > vm_normal_page() the equivalent of vm_normal_any_page(). It would mean
> > vm_normal_page() would return non-LRU device coherent pages, but to me at least
> > device coherent pages seem special and not what I'd expect from a function with
> > "normal" in the name.
> >
> > So I think it would be better to s/vm_normal_lru_page/vm_normal_page/ and keep
> > vm_normal_any_page() (or perhaps call it vm_any_page?). This is basically what
> > the previous incarnation of this feature did:
> >
> > struct page *_vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
> > pte_t pte, bool with_public_device);
> > #define vm_normal_page(vma, addr, pte) _vm_normal_page(vma, addr, pte, false)
> >
> > Except we should add:
> >
> > #define vm_normal_any_page(vma, addr, pte) _vm_normal_page(vma, addr, pte, true)
> >
>
> "normal" simply tells us that this is not a special mapping -- IOW, we
> want the VM to take a look at the memmap and not treat it like a PFN
> map. What we're changing is that we're now also returning non-lru pages.
> Fair enough, that's why we introduce vm_normal_lru_page() as a
> replacement where we really can only deal with lru pages.
>
> vm_normal_page vs vm_normal_lru_page is good enough. "lru" further
> limits what we get via vm_normal_page, that's even how it's implemented.
This naming makes sense to me.
Jason
next prev parent reply other threads:[~2022-03-17 13:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 17:26 [PATCH v1 0/3] split vm_normal_pages for LRU and non-LRU handling Alex Sierra
2022-03-10 17:26 ` [PATCH v1 1/3] mm: " Alex Sierra
2022-03-10 19:25 ` Matthew Wilcox
2022-03-10 21:58 ` Felix Kuehling
2022-03-17 2:50 ` Alistair Popple
2022-03-11 9:16 ` David Hildenbrand
2022-03-11 17:08 ` Felix Kuehling
2022-03-17 2:54 ` Alistair Popple
2022-03-17 8:13 ` David Hildenbrand
2022-03-17 13:25 ` Jason Gunthorpe [this message]
2022-03-10 17:26 ` [PATCH v1 2/3] tools: add more gup configs to hmm_gup selftests Alex Sierra
2022-03-10 17:26 ` [PATCH v1 3/3] tools: add selftests to hmm for COW in device memory Alex Sierra
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=20220317132543.GW11336@nvidia.com \
--to=jgg@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=alex.sierra@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=apopple@nvidia.com \
--cc=david@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=felix.kuehling@amd.com \
--cc=hch@lst.de \
--cc=jglisse@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=rcampbell@nvidia.com \
--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;
as well as URLs for NNTP newsgroup(s).