On 6/24/26 13:08, Wandun wrote:
> On 6/22/26 17:55, Vlastimil Babka (SUSE) wrote:
>> On 6/18/26 13:43, Wandun wrote:
>>> Yes, I wrote a test case that can reproduce it in a few second.
>>>
>>> The test case contains 3 steps:
>>> 1. mlockall
>>> 2. mmap file(2GB) + trigger file write page fault;
>>> 3. during step 1, trigger compact via /proc/sys/vm/compact_memory
>>>
>>>
>>> My reproduction environment is qemu with 4GB ram, 8 core, aarch64,
>>> preempt_rt and includes the tracepoint in patch 02.
>>> After running the reproduction program for a few seconds, the
>>> following output appears.
>>>
>>> repro-403 [004] ....1 101.270505: mm_compaction_isolate_folio:
>>> pfn=0x71e3a mode=0x0
> flags=referenced|uptodate|mlocked
>>> repro-403 [004] ....1 101.270507: mm_compaction_isolate_folio:
>>> pfn=0x71e3b mode=0x0
> flags=referenced|uptodate|mlocked
>>> repro-403 [004] ....1 101.270513: mm_compaction_isolate_folio:
>>> pfn=0x71e3c mode=0x0
> flags=referenced|uptodate|mlocked
>>> repro-403 [004] ....1 101.270515: mm_compaction_isolate_folio:
>>> pfn=0x71e3d mode=0x0
> flags=uptodate|mlocked
>>> repro-403 [004] ....1 101.270517: mm_compaction_isolate_folio:
>>> pfn=0x71e3e mode=0x0
> flags=uptodate|mlocked
>>> repro-403 [004] ....1 101.270520: mm_compaction_isolate_folio:
>>> pfn=0x71e3f mode=0x0
> flags=uptodate|mlocked
I applied your PATCH 2/3 to our kernel and checked with your reproducer,
I get similar output, e.g.
t_compact-2148 [005] ....1 515.320221: mm_compaction_isolate_folio:
pfn=0xe66c2 mode=0x0
flags=referenced|uptodate|active|swapbacked|mlocked
With your first patch applied, the amount of these messages decrease.
I was not able to apply your third patch to our (older) kernel.
However, we were not able to reproduce the actual race
(mlockall() process waiting on a migration PTE),
not in the past, not now. Might be hard to trigger that race.
> IIUC, more accurately, the migration entry in the page talbe is real a bad for
> RT process, because isolate page doesn't modify the page table, so memory
> access continues as usual, therefore a new idea occur.
>
> S1. In the mlock[all] syscall, if mlock_vma_pages_range hit a migration entry,
> then, it should wait for the migration to complete.
>
> S2. During the unmap phase of memory migration, prevent a page from being
> unmapped
> if the page's associated vma is markd with VM_LOCKED, similar to how
> reclaim is
> disabled for pages in a VM_LOCKED vma(try_to_unmap_one).
>
>
> For a page handled during the mlock[all] syscall:
> - if migration has been already finished, there is noting to do;
> - if migration is in progress and the migration etnry is already filled, we
> wait (S1)
> - if the page is in-fight, going to be isolated/migrated, S2 prevents the
> unmap.
>
> For a page handled during a page fault: VM_LOCKED is already set on the vma,
> so S2 guarantees it will not be unmapped, hence no migration entry.
I do not understand all details of this, but it looks good,
especially the S1 case makes a lot of sense for me.
Nitpick: I suggest to switch order of PATCH 1 and 2 for the next iteration,
introducing the tracepoint first and then improve the situation.
Thanks a lot for looking into this issue!
Best regards,
Alexander
--
KUKA Deutschland GmbH Board of Directors: Michael Jürgens (Chairman), Johan
Naten, Hui Zhang Registered Office: Augsburg HRB 14914
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorized
copying, disclosure or distribution of contents of this e-mail is strictly
forbidden.
Please consider the environment before printing this e-mail.
