The patch titled
Subject: mm: inline simpler case of page_remove_file_rmap()
has been added to the -mm mm-unstable branch. Its filename is
mm-inline-simpler-case-of-page_remove_file_rmap.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-inline-simpler-case-of-page_remove_file_rmap.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Subject: mm: inline simpler case of page_remove_file_rmap()
Date: Sun Oct 30 13:50:39 2022 -0700
Now that we have a simplified special case of 'page_remove_rmap()' that
doesn't deal with the 'compound' case and always gets a file-mapped (ie
not anonymous) page, it ended up doing just
lock_page_memcg(page);
page_remove_file_rmap(page, false);
unlock_page_memcg(page);
but 'page_remove_file_rmap()' is actually trivial when 'compound' is
false.
So just inline that non-compound case in the caller, and - like we did in
the previous commit for the anon pages - only do the memcg locking for the
parts that actually matter: the page statistics.
Also, as the previous commit did for anonymous pages, knowing we only get
called for the last-level page table entries allows for a further
simplification: we can get rid of the 'PageHuge(page)' case too.
You can't map a huge-page in a pte without splitting it (and the full code
in the generic page_remove_file_rmap() function has a comment to that
effect: "hugetlb pages are always mapped with pmds").
That means that the page_zap_file_rmap() case of that whole function is
really small and trivial.
Link: https://lore.kernel.org/all/B88D3073-440A-41C7-95F4-895D3F657EF2@xxxxxxxxx/
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: Nadav Amit <nadav.amit@xxxxxxxxx>
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: John Hubbard <jhubbard@xxxxxxxxxx>
Cc: Alexander Gordeev <agordeev@xxxxxxxxxxxxx>
Cc: Aneesh Kumar <aneesh.kumar@xxxxxxxxxxxxx>
Cc: Christian Borntraeger <borntraeger@xxxxxxxxxxxxx>
Cc: Gerald Schaefer <gerald.schaefer@xxxxxxxxxxxxx>
Cc: Heiko Carstens <hca@xxxxxxxxxxxxx>
Cc: Nick Piggin <npiggin@xxxxxxxxx>
Cc: Sven Schnelle <svens@xxxxxxxxxxxxx>
Cc: Vasily Gorbik <gor@xxxxxxxxxxxxx>
Cc: Will Deacon <will@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/rmap.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/mm/rmap.c~mm-inline-simpler-case-of-page_remove_file_rmap
+++ a/mm/rmap.c
@@ -1426,8 +1426,11 @@ static void page_remove_anon_compound_rm
*/
void page_zap_file_rmap(struct page *page)
{
+ if (!atomic_add_negative(-1, &page->_mapcount))
+ return;
+
lock_page_memcg(page);
- page_remove_file_rmap(page, false);
+ __dec_lruvec_page_state(page, NR_FILE_MAPPED);
unlock_page_memcg(page);
}
_
Patches currently in -mm which might be from torvalds@xxxxxxxxxxxxxxxxxxxx are
mm-introduce-simplified-versions-of-page_remove_rmap.patch
mm-inline-simpler-case-of-page_remove_file_rmap.patch
mm-re-unify-the-simplified-page_zap__rmap-function.patch
mm-delay-rmap-removal-until-after-tlb-flush.patch
