Re: [PATCH V2] mm/gup: Clear the LRU flag of a page before adding to LRU batch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





在 2024/7/30 6:06, Chris Li 写道:
On Sun, Jul 28, 2024 at 8:49 PM Ge Yang <yangge1116@xxxxxxx> wrote:



在 2024/7/28 6:33, Chris Li 写道:
Hello Ge Yang,

Sorry for joining this discussion late.

I recently found a regression on mm-unstable during my swap stress
test, using tmpfs to compile linux. The test hit OOM very soon after
the make spawn many cc processes.

This is preventing me from stress testing the swap allocator series on
mm-unstable and mm-stable. I finally spent some time doing a kernel
git bisect. It bisects down to this commit:

33dfe9204f29b415bbc0abb1a50642d1ba94f5e9 is the first bad commit
commit 33dfe9204f29b415bbc0abb1a50642d1ba94f5e9
Author: yangge <yangge1116@xxxxxxx>
Date:   Wed Jul 3 20:02:33 2024 +0800
      mm/gup: clear the LRU flag of a page before adding to LRU batch
   mm/swap.c | 43 +++++++++++++++++++++++++++++++------------
   1 file changed, 31 insertions(+), 12 deletions(-)
bisect found first bad commit


Here the git bisect log:
$ git bisect log
# bad: [66ebbdfdeb093e097399b1883390079cd4c3022b] Merge tag
'irq-msi-2024-07-22' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
# good: [0c3836482481200ead7b416ca80c68a29cfdaabd] Linux 6.10
git bisect start 'remotes/akpm/mm-stable' 'v6.10'
# good: [280e36f0d5b997173d014c07484c03a7f7750668] nsfs: use cleanup guard
git bisect good 280e36f0d5b997173d014c07484c03a7f7750668
# good: [07e773db19f16f4111795b658c4748da22c927bb] Merge tag
'tpmdd-next-6.11-rc1-roundtwo' of
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd
git bisect good 07e773db19f16f4111795b658c4748da22c927bb
# good: [ef035628c326af9aa645af1b91fbb72fdfec874e] Merge tag
'i2c-for-6.11-rc1-try2' of
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
git bisect good ef035628c326af9aa645af1b91fbb72fdfec874e
# good: [2c9b3512402ed192d1f43f4531fb5da947e72bd0] Merge tag
'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good 2c9b3512402ed192d1f43f4531fb5da947e72bd0
# bad: [30d77b7eef019fa4422980806e8b7cdc8674493e] mm/mglru: fix
ineffective protection calculation
git bisect bad 30d77b7eef019fa4422980806e8b7cdc8674493e
# good: [c02525a33969000fa7b595b743deb4d79804916b] ftrace: unpoison
ftrace_regs in ftrace_ops_list_func()
git bisect good c02525a33969000fa7b595b743deb4d79804916b
# good: [8ef6fd0e9ea83a792ba53882ddc6e0d38ce0d636] Merge branch
'mm-hotfixes-stable' into mm-stable to pick up "mm: fix crashes from
deferred split racing folio migration", needed by "mm: migrate: split
folio_migrate_mapping()".
git bisect good 8ef6fd0e9ea83a792ba53882ddc6e0d38ce0d636
# good: [a898530eea3d0ba08c17a60865995a3bb468d1bc] powerpc/64e: split
out nohash Book3E 64-bit code
git bisect good a898530eea3d0ba08c17a60865995a3bb468d1bc
# good: [00f58104202c472e487f0866fbd38832523fd4f9] mm: fix khugepaged
activation policy
git bisect good 00f58104202c472e487f0866fbd38832523fd4f9
# good: [53dabce2652fb854eae84609ce9c37429d5d87ba] mm, page_alloc: put
should_fail_alloc_page() back behing CONFIG_FAIL_PAGE_ALLOC
git bisect good 53dabce2652fb854eae84609ce9c37429d5d87ba
# good: [6ab42fe21c84d72da752923b4bd7075344f4a362] alloc_tag: fix
page_ext_get/page_ext_put sequence during page splitting
git bisect good 6ab42fe21c84d72da752923b4bd7075344f4a362
# bad: [33dfe9204f29b415bbc0abb1a50642d1ba94f5e9] mm/gup: clear the
LRU flag of a page before adding to LRU batch
git bisect bad 33dfe9204f29b415bbc0abb1a50642d1ba94f5e9
# good: [af649773fb25250cd22625af021fb6275c56a3ee] mm/numa_balancing:
teach mpol_to_str about the balancing mode
git bisect good af649773fb25250cd22625af021fb6275c56a3ee
# first bad commit: [33dfe9204f29b415bbc0abb1a50642d1ba94f5e9] mm/gup:
clear the LRU flag of a page before adding to LRU batch

I double checked this commit 33dfe9204f29b415bbc0abb1a50642d1ba94f5e9
("mm/gup: clear the LRU flag of a page before adding to LRU batch")
fail the swap stress test very quickly.

The previous commit af649773fb25250cd22625af021fb6275c56a3ee
("mm/numa_balancing: teach mpol_to_str about the balancing mode") can
pass the swap stress test fine.

Please feel free to send me patches to test out the issue. As it is, I
believe it is a regression on the swapping behavior.

Here is the dmesg of the OOM kill:

[   93.326752] cc1 invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL),
order=0, oom_score_adj=0
[   93.327330] CPU: 3 PID: 5225 Comm: cc1 Tainted: G          I
6.10.0-rc6+ #34
[   93.328277] Hardware name: HP ProLiant DL360 G7, BIOS P68 08/16/2015
[   93.328757] Call Trace:
[   93.328977]  <TASK>
[   93.329515]  dump_stack_lvl+0x5d/0x80
[   93.329842]  dump_header+0x44/0x18d
[   93.330422]  oom_kill_process.cold+0xa/0xaa
[   93.330723]  out_of_memory+0x219/0x4b0
[   93.331037]  mem_cgroup_out_of_memory+0x12d/0x160
[   93.331755]  try_charge_memcg+0x488/0x630
[   93.332044]  __mem_cgroup_charge+0x42/0xb0
[   93.332321]  do_anonymous_page+0x32a/0x8b0
[   93.332553]  ? __pte_offset_map+0x1b/0x180
[   93.332857]  __handle_mm_fault+0xc05/0x1080
[   93.333141]  ? sched_balance_trigger+0x14c/0x3f0
[   93.333840]  ? sched_tick+0xee/0x320
[   93.334142]  handle_mm_fault+0xcd/0x2a0
[   93.334419]  do_user_addr_fault+0x217/0x620
[   93.334694]  exc_page_fault+0x7e/0x180
[   93.334960]  asm_exc_page_fault+0x26/0x30
[   93.335194] RIP: 0033:0x147a0b3
[   93.335852] Code: a0 00 48 89 fb 49 89 f4 41 89 d5 74 7a 31 d2 31
f6 b9 01 00 00 00 bf 18 00 00 00 e8 97 b6 f8 ff 66 0f ef c0 66 41 83
3c 24 2b <4c> 89 60 10 48 89 c5 49 89 c6 0f 11 00 74 7e 48 8b 43 08 80
48 02
[   93.337577] RSP: 002b:00007ffe666e3e10 EFLAGS: 00010216
[   93.337966] RAX: 00007f4dd9d0e000 RBX: 00007ffe666e3e50 RCX: 00000000000000a9
[   93.338896] RDX: 0000000000000018 RSI: 0000000000000006 RDI: 00000000000000aa
[   93.339849] RBP: 00007f4dd9d0a0e0 R08: 0000000000000040 R09: 0000000000000001
[   93.340801] R10: 0000000000000000 R11: 0000000004c04560 R12: 00007f4dd9d04fd8
[   93.341675] R13: 0000000000000004 R14: 0000000000000000 R15: 000000007ffea943
[   93.342584]  </TASK>
[   93.342762] memory: usage 481280kB, limit 481280kB, failcnt 9789

I can't reproduce this problem, using tmpfs to compile linux.
Seems you limit the memory size used to compile linux, which leads to
OOM. May I ask why the memory size is limited to 481280kB? Do I also
need to limit the memory size to 481280kB to test?

Yes, you need to limit the cgroup memory size to force the swap
action. I am using memory.max = 470M.

I believe other values e.g. 800M can trigger it as well. The reason to
limit the memory to cause the swap action.
The goal is to intentionally overwhelm the memory load and let the
swap system do its job. The 470M is chosen to cause a lot of swap
action but not too high to cause OOM kills in normal kernels.
In another word, high enough swap pressure but not too high to bust
into OOM kill. e.g. I verify that, with your patch reverted, the
mm-stable kernel can sustain this level of swap pressure (470M)
without OOM kill.

I borrowed the 470M magic value from Hugh and verified it works with
my test system. Huge has a similar swab test up which is more
complicated than mine. It is the inspiration of my swap stress test
setup.

FYI, I am using "make -j32" on a machine with 12 cores (24
hyperthreading). My typical swap usage is about 3-5G. I set my
swapfile size to about 20G.
I am using zram or ssd as the swap backend.  Hope that helps you
reproduce the problem.

Hi Chris,

I try to construct the experiment according to your suggestions above. High swap pressure can be triggered, but OOM can't be reproduced. The specific steps are as follows:
root@ubuntu-server-2204:/home/yangge# cp workspace/linux/ /dev/shm/ -rf
root@ubuntu-server-2204:/home/yangge# sync
root@ubuntu-server-2204:/home/yangge# echo 3 > /proc/sys/vm/drop_caches
root@ubuntu-server-2204:/home/yangge# cd /sys/fs/cgroup/
root@ubuntu-server-2204:/sys/fs/cgroup/# mkdir kernel-build
root@ubuntu-server-2204:/sys/fs/cgroup/# cd kernel-build
root@ubuntu-server-2204:/sys/fs/cgroup/kernel-build# echo 470M > memory.max
root@ubuntu-server-2204:/sys/fs/cgroup/kernel-build# echo $$ > cgroup.procs
root@ubuntu-server-2204:/sys/fs/cgroup/kernel-build# cd /dev/shm/linux/
root@ubuntu-server-2204:/dev/shm/linux# make clean && make -j24

Please help to see which step does not meet your requirements.


Chris


[   93.343556] swap: usage 123404kB, limit 9007199254740988kB, failcnt 0
[   93.343984] Memory cgroup stats for /build-kernel-tmpfs:
[   93.344051] anon 461377536
[   93.344586] file 10264576
[   93.344795] kernel 20480000
[   93.344987] kernel_stack 2146304
[   93.345615] pagetables 9916416
[   93.346283] sec_pagetables 0
[   93.346878] percpu 54496
[   93.347080] sock 0
[   93.347607] vmalloc 0
[   93.347837] shmem 24576
[   93.347984] zswap 0
[   93.348510] zswapped 0
[   93.348661] file_mapped 9805824
[   93.349286] file_dirty 0
[   93.349484] file_writeback 0
[   93.350085] swapcached 24576
[   93.350706] anon_thp 213909504
[   93.351335] file_thp 0
[   93.351544] shmem_thp 0
[   93.351681] inactive_anon 180965376
[   93.352348] active_anon 291487744
[   93.352993] inactive_file 1298432
[   93.353632] active_file 7987200
[   93.354281] unevictable 0
[   93.354483] slab_reclaimable 943096
[   93.355085] slab_unreclaimable 6340520
[   93.355369] slab 7283616
[   93.355597] workingset_refault_anon 1138
[   93.355857] workingset_refault_file 180
[   93.356135] workingset_activate_anon 627
[   93.356410] workingset_activate_file 123
[   93.356694] workingset_restore_anon 579
[   93.357001] workingset_restore_file 115
[   93.382485] workingset_nodereclaim 0
[   93.457426] pgscan 101315
[   93.457631] pgsteal 51494
[   93.457843] pgscan_kswapd 0
[   93.458033] pgscan_direct 101315
[   93.458725] pgscan_khugepaged 0
[   93.459494] pgsteal_kswapd 0
[   93.460338] pgsteal_direct 51494
[   93.461046] pgsteal_khugepaged 0
[   93.461701] pgfault 994774
[   93.461895] pgmajfault 1839
[   93.462123] pgrefill 134581
[   93.462315] pgactivate 32506
[   93.463086] pgdeactivate 0
[   93.463314] pglazyfree 0
[   93.463527] pglazyfreed 0
[   93.463727] zswpin 0
[   93.463912] zswpout 0
[   93.464114] zswpwb 0
[   93.464321] thp_fault_alloc 485
[   93.464963] thp_collapse_alloc 0
[   93.465578] thp_swpout 4
[   93.465815] thp_swpout_fallback 0
[   93.466457] Tasks state (memory values in pages):
[   93.467153] [  pid  ]   uid  tgid total_vm      rss rss_anon
rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
[   93.467917] [   1461]  1000  1461     1795      530       53
477         0    45056        0             0 kbench
[   93.468600] [   4170]  1000  4170      636      321        0
321         0    45056        0             0 time
[   93.569307] [   4171]  1000  4171     3071      810       48
762         0    69632       48             0 make
[   93.570111] [   4172]  1000  4172     2706      827      144
683         0    65536      192             0 make
[   93.571015] [   4951]  1000  4951     2733      791      144
647         0    61440      192             0 make
[   93.571747] [   4956]  1000  4956     2560      852      144
708         0    69632        0             0 make
[   93.572478] [   4957]  1000  4957     2541      803       96
707         0    61440       96             0 make
[   93.573244] [   4958]  1000  4958     2541      750       96
654         0    53248       48             0 make
[   93.574016] [   4960]  1000  4960     2565      753       96
657         0    65536       48             0 make
[   93.674651] [   4961]  1000  4961     2538      837      144
693         0    53248        0             0 make
[   93.675446] [   4962]  1000  4962     2569      845      192
653         0    69632        0             0 make
[   93.676220] [   4963]  1000  4963     2567      852      192
660         0    57344        0             0 make
[   93.676946] [   4964]  1000  4964     2536      901      192
709         0    65536        0             0 make
[   93.677679] [   4965]  1000  4965     2540      887      192
695         0    61440        0             0 make
[   93.678377] [   4967]  1000  4967     2563      853      144
709         0    61440       48             0 make
[   93.679168] [   4969]  1000  4969     2538      836      144
692         0    57344       48             0 make
[   93.679937] [   4973]  1000  4973     2535      827      144
683         0    61440       48             0 make
[   93.680628] [   4976]  1000  4976     2571      878      192
686         0    57344        0             0 make
[   93.681397] [   4977]  1000  4977     2534      850      192
658         0    53248        0             0 make
[   93.682121] [   4978]  1000  4978     1797      766       48
718         0    49152        0             0 sh
[   93.683272] [   4980]  1000  4980     2540      839      192
647         0    65536       48             0 make
[   93.709270] [   4982]  1000  4982     2539      853      144
709         0    65536        0             0 make
[   93.784725] [   4983]  1000  4983     1798      885       96
789         0    61440        0             0 sh
[   93.785895] [   4984]  1000  4984     2539      878      192
686         0    57344        0             0 make
[   93.786661] [   4986]  1000  4986     2537      863      192
671         0    61440        0             0 make
[   93.787378] [   4988]  1000  4988     2540      824      144
680         0    61440       48             0 make
[   93.788060] [   4989]  1000  4989     2538      792      144
648         0    65536        0             0 make
[   93.788873] [   4990]  1000  4990     1282      810       48
762         0    45056        0             0 gcc

Chris

On Fri, Jun 21, 2024 at 11:48 PM <yangge1116@xxxxxxx> wrote:

From: yangge <yangge1116@xxxxxxx>

If a large number of CMA memory are configured in system (for example, the
CMA memory accounts for 50% of the system memory), starting a virtual
virtual machine, it will call pin_user_pages_remote(..., FOLL_LONGTERM,
...) to pin memory.  Normally if a page is present and in CMA area,
pin_user_pages_remote() will migrate the page from CMA area to non-CMA
area because of FOLL_LONGTERM flag. But the current code will cause the
migration failure due to unexpected page refcounts, and eventually cause
the virtual machine fail to start.

If a page is added in LRU batch, its refcount increases one, remove the
page from LRU batch decreases one. Page migration requires the page is not
referenced by others except page mapping. Before migrating a page, we
should try to drain the page from LRU batch in case the page is in it,
however, folio_test_lru() is not sufficient to tell whether the page is
in LRU batch or not, if the page is in LRU batch, the migration will fail.

To solve the problem above, we modify the logic of adding to LRU batch.
Before adding a page to LRU batch, we clear the LRU flag of the page so
that we can check whether the page is in LRU batch by folio_test_lru(page).
Seems making the LRU flag of the page invisible a long time is no problem,
because a new page is allocated from buddy and added to the lru batch,
its LRU flag is also not visible for a long time.

Cc: <stable@xxxxxxxxxxxxxxx>
Signed-off-by: yangge <yangge1116@xxxxxxx>
---
   mm/swap.c | 43 +++++++++++++++++++++++++++++++------------
   1 file changed, 31 insertions(+), 12 deletions(-)

diff --git a/mm/swap.c b/mm/swap.c
index dc205bd..9caf6b0 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -211,10 +211,6 @@ static void folio_batch_move_lru(struct folio_batch *fbatch, move_fn_t move_fn)
          for (i = 0; i < folio_batch_count(fbatch); i++) {
                  struct folio *folio = fbatch->folios[i];

-               /* block memcg migration while the folio moves between lru */
-               if (move_fn != lru_add_fn && !folio_test_clear_lru(folio))
-                       continue;
-
                  folio_lruvec_relock_irqsave(folio, &lruvec, &flags);
                  move_fn(lruvec, folio);

@@ -255,11 +251,16 @@ static void lru_move_tail_fn(struct lruvec *lruvec, struct folio *folio)
   void folio_rotate_reclaimable(struct folio *folio)
   {
          if (!folio_test_locked(folio) && !folio_test_dirty(folio) &&
-           !folio_test_unevictable(folio) && folio_test_lru(folio)) {
+           !folio_test_unevictable(folio)) {
                  struct folio_batch *fbatch;
                  unsigned long flags;

                  folio_get(folio);
+               if (!folio_test_clear_lru(folio)) {
+                       folio_put(folio);
+                       return;
+               }
+
                  local_lock_irqsave(&lru_rotate.lock, flags);
                  fbatch = this_cpu_ptr(&lru_rotate.fbatch);
                  folio_batch_add_and_move(fbatch, folio, lru_move_tail_fn);
@@ -352,11 +353,15 @@ static void folio_activate_drain(int cpu)

   void folio_activate(struct folio *folio)
   {
-       if (folio_test_lru(folio) && !folio_test_active(folio) &&
-           !folio_test_unevictable(folio)) {
+       if (!folio_test_active(folio) && !folio_test_unevictable(folio)) {
                  struct folio_batch *fbatch;

                  folio_get(folio);
+               if (!folio_test_clear_lru(folio)) {
+                       folio_put(folio);
+                       return;
+               }
+
                  local_lock(&cpu_fbatches.lock);
                  fbatch = this_cpu_ptr(&cpu_fbatches.activate);
                  folio_batch_add_and_move(fbatch, folio, folio_activate_fn);
@@ -700,6 +705,11 @@ void deactivate_file_folio(struct folio *folio)
                  return;

          folio_get(folio);
+       if (!folio_test_clear_lru(folio)) {
+               folio_put(folio);
+               return;
+       }
+
          local_lock(&cpu_fbatches.lock);
          fbatch = this_cpu_ptr(&cpu_fbatches.lru_deactivate_file);
          folio_batch_add_and_move(fbatch, folio, lru_deactivate_file_fn);
@@ -716,11 +726,16 @@ void deactivate_file_folio(struct folio *folio)
    */
   void folio_deactivate(struct folio *folio)
   {
-       if (folio_test_lru(folio) && !folio_test_unevictable(folio) &&
-           (folio_test_active(folio) || lru_gen_enabled())) {
+       if (!folio_test_unevictable(folio) && (folio_test_active(folio) ||
+           lru_gen_enabled())) {
                  struct folio_batch *fbatch;

                  folio_get(folio);
+               if (!folio_test_clear_lru(folio)) {
+                       folio_put(folio);
+                       return;
+               }
+
                  local_lock(&cpu_fbatches.lock);
                  fbatch = this_cpu_ptr(&cpu_fbatches.lru_deactivate);
                  folio_batch_add_and_move(fbatch, folio, lru_deactivate_fn);
@@ -737,12 +752,16 @@ void folio_deactivate(struct folio *folio)
    */
   void folio_mark_lazyfree(struct folio *folio)
   {
-       if (folio_test_lru(folio) && folio_test_anon(folio) &&
-           folio_test_swapbacked(folio) && !folio_test_swapcache(folio) &&
-           !folio_test_unevictable(folio)) {
+       if (folio_test_anon(folio) && folio_test_swapbacked(folio) &&
+           !folio_test_swapcache(folio) && !folio_test_unevictable(folio)) {
                  struct folio_batch *fbatch;

                  folio_get(folio);
+               if (!folio_test_clear_lru(folio)) {
+                       folio_put(folio);
+                       return;
+               }
+
                  local_lock(&cpu_fbatches.lock);
                  fbatch = this_cpu_ptr(&cpu_fbatches.lru_lazyfree);
                  folio_batch_add_and_move(fbatch, folio, lru_lazyfree_fn);
--
2.7.4








[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux