From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org, ziy@nvidia.com, willy@infradead.org,
vbabka@suse.cz, tytso@mit.edu, songliubraving@fb.com,
song@kernel.org, riel@surriel.com, linmiaohe@huawei.com,
kirill.shutemov@linux.intel.com, shy828301@gmail.com,
akpm@linux-foundation.org
Subject: [merged mm-stable] mm-mmap-register-suitable-readonly-file-vmas-for-khugepaged.patch removed from -mm tree
Date: Thu, 19 May 2022 15:25:32 -0700 [thread overview]
Message-ID: <20220519222533.21B7DC385AA@smtp.kernel.org> (raw)
The quilt patch titled
Subject: mm: mmap: register suitable readonly file vmas for khugepaged
has been removed from the -mm tree. Its filename was
mm-mmap-register-suitable-readonly-file-vmas-for-khugepaged.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Yang Shi <shy828301@gmail.com>
Subject: mm: mmap: register suitable readonly file vmas for khugepaged
The readonly FS THP relies on khugepaged to collapse THP for suitable
vmas. But the behavior is inconsistent for "always" mode
(https://lore.kernel.org/linux-mm/00f195d4-d039-3cf2-d3a1-a2c88de397a0@suse.cz/).
The "always" mode means THP allocation should be tried all the time and
khugepaged should try to collapse THP all the time. Of course the
allocation and collapse may fail due to other factors and conditions.
Currently file THP may not be collapsed by khugepaged even though all the
conditions are met. That does break the semantics of "always" mode.
So make sure readonly FS vmas are registered to khugepaged to fix the
break.
Register suitable vmas in common mmap path, that could cover both readonly
FS vmas and shmem vmas, so remove the khugepaged calls in shmem.c.
Still need to keep the khugepaged call in vma_merge() since vma_merge() is
called in a lot of places, for example, madvise, mprotect, etc.
Link: https://lkml.kernel.org/r/20220510203222.24246-9-shy828301@gmail.com
Signed-off-by: Yang Shi <shy828301@gmail.com>
Reported-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Vlastmil Babka <vbabka@suse.cz>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Zi Yan <ziy@nvidia.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Song Liu <song@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/mmap.c | 7 +++++++
mm/shmem.c | 4 ----
2 files changed, 7 insertions(+), 4 deletions(-)
--- a/mm/mmap.c~mm-mmap-register-suitable-readonly-file-vmas-for-khugepaged
+++ a/mm/mmap.c
@@ -1847,6 +1847,13 @@ unsigned long mmap_region(struct file *f
}
vma_link(mm, vma, prev, rb_link, rb_parent);
+
+ /*
+ * vma_merge() calls khugepaged_enter_vma() either, the below
+ * call covers the non-merge case.
+ */
+ khugepaged_enter_vma(vma, vma->vm_flags);
+
/* Once vma denies write, undo our temporary denial count */
unmap_writable:
if (file && vm_flags & VM_SHARED)
--- a/mm/shmem.c~mm-mmap-register-suitable-readonly-file-vmas-for-khugepaged
+++ a/mm/shmem.c
@@ -34,7 +34,6 @@
#include <linux/export.h>
#include <linux/swap.h>
#include <linux/uio.h>
-#include <linux/khugepaged.h>
#include <linux/hugetlb.h>
#include <linux/fs_parser.h>
#include <linux/swapfile.h>
@@ -2232,7 +2231,6 @@ static int shmem_mmap(struct file *file,
file_accessed(file);
vma->vm_ops = &shmem_vm_ops;
- khugepaged_enter_vma(vma, vma->vm_flags);
return 0;
}
@@ -4133,8 +4131,6 @@ int shmem_zero_setup(struct vm_area_stru
vma->vm_file = file;
vma->vm_ops = &shmem_vm_ops;
- khugepaged_enter_vma(vma, vma->vm_flags);
-
return 0;
}
_
Patches currently in -mm which might be from shy828301@gmail.com are
mm-rmap-use-the-correct-parameter-name-for-define_page_vma_walk.patch
mm-pvmw-check-possible-huge-pmd-map-by-transhuge_vma_suitable.patch
reply other threads:[~2022-05-19 22:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20220519222533.21B7DC385AA@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=riel@surriel.com \
--cc=shy828301@gmail.com \
--cc=song@kernel.org \
--cc=songliubraving@fb.com \
--cc=tytso@mit.edu \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/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.