The patch titled
Subject: mm: thp: fix false negative of shmem vma's THP eligibility
has been added to the -mm tree. Its filename is
mm-thp-fix-false-negative-of-shmem-vmas-thp-eligibility.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-thp-fix-false-negative-of-shmem-vmas-thp-eligibility.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-thp-fix-false-negative-of-shmem-vmas-thp-eligibility.patch
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 and is updated
there every 3-4 working days
------------------------------------------------------
From: Yang Shi <yang.shi@xxxxxxxxxxxxxxxxx>
Subject: mm: thp: fix false negative of shmem vma's THP eligibility
7635d9cbe832 ("mm, thp, proc: report THP eligibility for each vma")
introduced THPeligible bit for processes' smaps. But, when checking the
eligibility for shmem vma, __transparent_hugepage_enabled() is called to
override the result from shmem_huge_enabled(). It may result in the
anonymous vma's THP flag override shmem's. For example, running a simple
test which create THP for shmem, but with anonymous THP disabled, when
reading the process's smaps, it may show:
7fc92ec00000-7fc92f000000 rw-s 00000000 00:14 27764 /dev/shm/test
Size: 4096 kB
...
[snip]
...
ShmemPmdMapped: 4096 kB
...
[snip]
...
THPeligible: 0
And, /proc/meminfo does show THP allocated and PMD mapped too:
ShmemHugePages: 4096 kB
ShmemPmdMapped: 4096 kB
This doesn't make too much sense. The shmem objects should be treated
separately from anonymous THP. Calling shmem_huge_enabled() with checking
MMF_DISABLE_THP sounds good enough. And, we could skip stack and
dax vma check since we already checked if the vma is shmem already.
Also check if vma is suitable for THP by calling
transhuge_vma_suitable().
And minor fix to smaps output format and documentation.
Link: http://lkml.kernel.org/r/1560401041-32207-3-git-send-email-yang.shi@xxxxxxxxxxxxxxxxx
Fixes: 7635d9cbe832 ("mm, thp, proc: report THP eligibility for each vma")
Signed-off-by: Yang Shi <yang.shi@xxxxxxxxxxxxxxxxx>
Cc: Hugh Dickins <hughd@xxxxxxxxxx>
Cc: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Vlastimil Babka <vbabka@xxxxxxx>
Cc: David Rientjes <rientjes@xxxxxxxxxx>
Cc: Andrea Arcangeli <aarcange@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
Documentation/filesystems/proc.txt | 4 ++--
fs/proc/task_mmu.c | 3 ++-
mm/huge_memory.c | 9 +++++++--
mm/shmem.c | 3 +++
4 files changed, 14 insertions(+), 5 deletions(-)
--- a/Documentation/filesystems/proc.txt~mm-thp-fix-false-negative-of-shmem-vmas-thp-eligibility
+++ a/Documentation/filesystems/proc.txt
@@ -477,8 +477,8 @@ replaced by copy-on-write) part of the u
"SwapPss" shows proportional swap share of this mapping. Unlike "Swap", this
does not take into account swapped out page of underlying shmem objects.
"Locked" indicates whether the mapping is locked in memory or not.
-"THPeligible" indicates whether the mapping is eligible for THP pages - 1 if
-true, 0 otherwise.
+"THPeligible" indicates whether the mapping is eligible for allocating THP
+pages - 1 if true, 0 otherwise. It just shows the current status.
"VmFlags" field deserves a separate description. This member represents the kernel
flags associated with the particular virtual memory area in two letter encoded
--- a/fs/proc/task_mmu.c~mm-thp-fix-false-negative-of-shmem-vmas-thp-eligibility
+++ a/fs/proc/task_mmu.c
@@ -800,7 +800,8 @@ static int show_smap(struct seq_file *m,
__show_smap(m, &mss);
- seq_printf(m, "THPeligible: %d\n", transparent_hugepage_enabled(vma));
+ seq_printf(m, "THPeligible: %d\n",
+ transparent_hugepage_enabled(vma));
if (arch_pkeys_enabled())
seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
--- a/mm/huge_memory.c~mm-thp-fix-false-negative-of-shmem-vmas-thp-eligibility
+++ a/mm/huge_memory.c
@@ -65,10 +65,15 @@ struct page *huge_zero_page __read_mostl
bool transparent_hugepage_enabled(struct vm_area_struct *vma)
{
+ /* The addr is used to check if the vma size fits */
+ unsigned long addr = (vma->vm_end & HPAGE_PMD_MASK) - HPAGE_PMD_SIZE;
+
+ if (!transhuge_vma_suitable(vma, addr))
+ return false;
if (vma_is_anonymous(vma))
return __transparent_hugepage_enabled(vma);
- if (vma_is_shmem(vma) && shmem_huge_enabled(vma))
- return __transparent_hugepage_enabled(vma);
+ if (vma_is_shmem(vma))
+ return shmem_huge_enabled(vma);
return false;
}
--- a/mm/shmem.c~mm-thp-fix-false-negative-of-shmem-vmas-thp-eligibility
+++ a/mm/shmem.c
@@ -3872,6 +3872,9 @@ bool shmem_huge_enabled(struct vm_area_s
loff_t i_size;
pgoff_t off;
+ if ((vma->vm_flags & VM_NOHUGEPAGE) ||
+ test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
+ return false;
if (shmem_huge == SHMEM_HUGE_FORCE)
return true;
if (shmem_huge == SHMEM_HUGE_DENY)
_
Patches currently in -mm which might be from yang.shi@xxxxxxxxxxxxxxxxx are
mm-filemap-correct-the-comment-about-vm_fault_retry.patch
mm-vmscan-remove-double-slab-pressure-by-incing-sc-nr_scanned.patch
mm-vmscan-correct-some-vmscan-counters-for-thp-swapout.patch
mm-thp-make-transhuge_vma_suitable-available-for-anonymous-thp.patch
mm-thp-fix-false-negative-of-shmem-vmas-thp-eligibility.patch
