From: Christoph Hellwig <hch@lst.de>
To: Alex Sierra <alex.sierra@amd.com>
Cc: rcampbell@nvidia.com, willy@infradead.org, david@redhat.com,
Felix.Kuehling@amd.com, apopple@nvidia.com,
amd-gfx@lists.freedesktop.org, linux-xfs@vger.kernel.org,
linux-mm@kvack.org, jglisse@redhat.com,
dri-devel@lists.freedesktop.org, jgg@nvidia.com,
akpm@linux-foundation.org, linux-ext4@vger.kernel.org,
hch@lst.de
Subject: Re: [PATCH v2 1/3] mm: add vm_normal_lru_pages for LRU handled pages only
Date: Thu, 31 Mar 2022 10:53:41 +0200 [thread overview]
Message-ID: <20220331085341.GA22102@lst.de> (raw)
In-Reply-To: <20220330212537.12186-2-alex.sierra@amd.com>
> - page = vm_normal_page(vma, addr, pte);
> + page = vm_normal_lru_page(vma, addr, pte);
Why can't this deal with ZONE_DEVICE pages? It certainly has
nothing do with a LRU I think. In fact being able to have
stats that count say the number of device pages here would
probably be useful at some point.
In general I find the vm_normal_lru_page vs vm_normal_page
API highly confusing. An explicit check for zone device pages
in the dozen or so spots that care has a much better documentation
value, especially if accompanied by comments where it isn't entirely
obvious.
> page = follow_page(vma, addr,
> - FOLL_GET | FOLL_MIGRATION | FOLL_REMOTE);
> + FOLL_GET | FOLL_MIGRATION | FOLL_REMOTE | FOLL_LRU);
Overly long line here.
> +/*
> + * NOTE: Technically this should goto check_pfn label. However, page->_mapcount
> + * is never incremented for device pages that are mmap through DAX mechanism
> + * using pmem driver mounted into ext4 filesystem. When these pages are unmap,
> + * zap_pte_range is called and vm_normal_page return a valid page with
> + * page_mapcount() = 0, before page_remove_rmap is called.
> + */
Please properly indent comments.
> + * zone, as long as the pte's are present and vm_normal_lru_page() succeeds. These
> * pages also get pinned.
Another overly long line here.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Alex Sierra <alex.sierra@amd.com>
Cc: jgg@nvidia.com, david@redhat.com, Felix.Kuehling@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, apopple@nvidia.com,
willy@infradead.org, akpm@linux-foundation.org
Subject: Re: [PATCH v2 1/3] mm: add vm_normal_lru_pages for LRU handled pages only
Date: Thu, 31 Mar 2022 10:53:41 +0200 [thread overview]
Message-ID: <20220331085341.GA22102@lst.de> (raw)
In-Reply-To: <20220330212537.12186-2-alex.sierra@amd.com>
> - page = vm_normal_page(vma, addr, pte);
> + page = vm_normal_lru_page(vma, addr, pte);
Why can't this deal with ZONE_DEVICE pages? It certainly has
nothing do with a LRU I think. In fact being able to have
stats that count say the number of device pages here would
probably be useful at some point.
In general I find the vm_normal_lru_page vs vm_normal_page
API highly confusing. An explicit check for zone device pages
in the dozen or so spots that care has a much better documentation
value, especially if accompanied by comments where it isn't entirely
obvious.
> page = follow_page(vma, addr,
> - FOLL_GET | FOLL_MIGRATION | FOLL_REMOTE);
> + FOLL_GET | FOLL_MIGRATION | FOLL_REMOTE | FOLL_LRU);
Overly long line here.
> +/*
> + * NOTE: Technically this should goto check_pfn label. However, page->_mapcount
> + * is never incremented for device pages that are mmap through DAX mechanism
> + * using pmem driver mounted into ext4 filesystem. When these pages are unmap,
> + * zap_pte_range is called and vm_normal_page return a valid page with
> + * page_mapcount() = 0, before page_remove_rmap is called.
> + */
Please properly indent comments.
> + * zone, as long as the pte's are present and vm_normal_lru_page() succeeds. These
> * pages also get pinned.
Another overly long line here.
next prev parent reply other threads:[~2022-03-31 13:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 21:25 [PATCH v2 0/3] split vm_normal_pages for LRU and non-LRU handling Alex Sierra
2022-03-30 21:25 ` Alex Sierra
2022-03-30 21:25 ` [PATCH v2 1/3] mm: add vm_normal_lru_pages for LRU handled pages only Alex Sierra
2022-03-30 21:25 ` Alex Sierra
2022-03-31 8:53 ` Christoph Hellwig [this message]
2022-03-31 8:53 ` Christoph Hellwig
2022-03-31 8:55 ` David Hildenbrand
2022-03-31 8:55 ` David Hildenbrand
2022-03-31 8:57 ` Christoph Hellwig
2022-03-31 8:57 ` Christoph Hellwig
2022-04-01 20:08 ` Felix Kuehling
2022-04-01 20:08 ` Felix Kuehling
2022-04-04 17:38 ` Jason Gunthorpe
2022-04-04 17:38 ` Jason Gunthorpe
2022-04-04 19:22 ` Sierra Guiza, Alejandro (Alex)
2022-04-04 19:22 ` Sierra Guiza, Alejandro (Alex)
2022-03-30 21:25 ` [PATCH v2 2/3] tools: add more gup configs to hmm_gup selftests Alex Sierra
2022-03-30 21:25 ` Alex Sierra
2022-03-30 21:25 ` [PATCH v2 3/3] tools: add selftests to hmm for COW in device memory Alex Sierra
2022-03-30 21:25 ` 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=20220331085341.GA22102@lst.de \
--to=hch@lst.de \
--cc=Felix.Kuehling@amd.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=jgg@nvidia.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.