* [PATCH mmotm] mm/thp: ClearPageDoubleMap in first page_add_file_rmap()
@ 2022-03-03 1:50 Hugh Dickins
2022-03-03 20:12 ` Yang Shi
0 siblings, 1 reply; 2+ messages in thread
From: Hugh Dickins @ 2022-03-03 1:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: Kirill A. Shutemov, Yang Shi, linux-kernel, linux-mm
PageDoubleMap is maintained differently for anon and for shmem+file:
the shmem+file one was never cleared, because a safe place to do so
could not be found; so it would blight future use of the cached
hugepage until evicted.
See https://lore.kernel.org/lkml/1571938066-29031-1-git-send-email-yang.shi@linux.alibaba.com/
But page_add_file_rmap() does provide a safe place to do so (though
later than one might wish): allowing testing to return to an initial
state without a damaging drop_caches.
Fixes: 9a73f61bdb8a ("thp, mlock: do not mlock PTE-mapped file huge pages")
Signed-off-by: Hugh Dickins <hughd@google.com>
---
mm/rmap.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1251,6 +1251,17 @@ void page_add_file_rmap(struct page *page,
}
if (!atomic_inc_and_test(compound_mapcount_ptr(page)))
goto out;
+
+ /*
+ * It is racy to ClearPageDoubleMap in page_remove_file_rmap();
+ * but page lock is held by all page_add_file_rmap() compound
+ * callers, and SetPageDoubleMap below warns if !PageLocked:
+ * so here is a place that DoubleMap can be safely cleared.
+ */
+ VM_WARN_ON_ONCE(!PageLocked(page));
+ if (nr == nr_pages && PageDoubleMap(page))
+ ClearPageDoubleMap(page);
+
if (PageSwapBacked(page))
__mod_lruvec_page_state(page, NR_SHMEM_PMDMAPPED,
nr_pages);
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH mmotm] mm/thp: ClearPageDoubleMap in first page_add_file_rmap()
2022-03-03 1:50 [PATCH mmotm] mm/thp: ClearPageDoubleMap in first page_add_file_rmap() Hugh Dickins
@ 2022-03-03 20:12 ` Yang Shi
0 siblings, 0 replies; 2+ messages in thread
From: Yang Shi @ 2022-03-03 20:12 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Kirill A. Shutemov, Linux Kernel Mailing List, Linux MM
On Wed, Mar 2, 2022 at 5:50 PM Hugh Dickins <hughd@google.com> wrote:
>
> PageDoubleMap is maintained differently for anon and for shmem+file:
> the shmem+file one was never cleared, because a safe place to do so
> could not be found; so it would blight future use of the cached
> hugepage until evicted.
>
> See https://lore.kernel.org/lkml/1571938066-29031-1-git-send-email-yang.shi@linux.alibaba.com/
>
> But page_add_file_rmap() does provide a safe place to do so (though
> later than one might wish): allowing testing to return to an initial
> state without a damaging drop_caches.
>
> Fixes: 9a73f61bdb8a ("thp, mlock: do not mlock PTE-mapped file huge pages")
> Signed-off-by: Hugh Dickins <hughd@google.com>
> ---
>
> mm/rmap.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1251,6 +1251,17 @@ void page_add_file_rmap(struct page *page,
> }
> if (!atomic_inc_and_test(compound_mapcount_ptr(page)))
> goto out;
> +
> + /*
> + * It is racy to ClearPageDoubleMap in page_remove_file_rmap();
> + * but page lock is held by all page_add_file_rmap() compound
> + * callers, and SetPageDoubleMap below warns if !PageLocked:
> + * so here is a place that DoubleMap can be safely cleared.
> + */
> + VM_WARN_ON_ONCE(!PageLocked(page));
> + if (nr == nr_pages && PageDoubleMap(page))
> + ClearPageDoubleMap(page);
Nice idea!
Reviewed-by: Yang Shi <shy828301@gmail.com>
> +
> if (PageSwapBacked(page))
> __mod_lruvec_page_state(page, NR_SHMEM_PMDMAPPED,
> nr_pages);
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-03-03 20:12 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-03 1:50 [PATCH mmotm] mm/thp: ClearPageDoubleMap in first page_add_file_rmap() Hugh Dickins
2022-03-03 20:12 ` Yang Shi
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).