| Message ID | 20241002012042.2753174-1-nphamcs@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | remove SWAP_MAP_SHMEM | expand |
On Tue, Oct 1, 2024 at 6:20 PM Nhat Pham <nphamcs@gmail.com> wrote: > > Changelog: > v2: > * Fix a WARN in the shmem THP swap path. Thanks Baolin, Yosry, and Barry > for the report and the discussion on how to solve it. Hi Baolin, could you run your stress program again on this version? FWIW, I was able to trigger 64kb mTHP swap in shmem + no-fallback swapout, so I think the issue is fixed.
On Tue, Oct 1, 2024 at 6:22 PM Nhat Pham <nphamcs@gmail.com> wrote: > > Hi Baolin, could you run your stress program again on this version? > FWIW, I was able to trigger 64kb mTHP swap in shmem + no-fallback > swapout, so I think the issue is fixed. Ooops, I think I missed Baolin in the cc. My apologies.
On 2024/10/2 09:22, Nhat Pham wrote: > On Tue, Oct 1, 2024 at 6:20 PM Nhat Pham <nphamcs@gmail.com> wrote: >> >> Changelog: >> v2: >> * Fix a WARN in the shmem THP swap path. Thanks Baolin, Yosry, and Barry >> for the report and the discussion on how to solve it. > > Hi Baolin, could you run your stress program again on this version? > FWIW, I was able to trigger 64kb mTHP swap in shmem + no-fallback > swapout, so I think the issue is fixed. Sure. I'm just back from vacation, and will find some time this week to test it.
On 2024/10/2 09:22, Nhat Pham wrote: > On Tue, Oct 1, 2024 at 6:20 PM Nhat Pham <nphamcs@gmail.com> wrote: >> >> Changelog: >> v2: >> * Fix a WARN in the shmem THP swap path. Thanks Baolin, Yosry, and Barry >> for the report and the discussion on how to solve it. > > Hi Baolin, could you run your stress program again on this version? > FWIW, I was able to trigger 64kb mTHP swap in shmem + no-fallback > swapout, so I think the issue is fixed. I tested it on my platform, and no issues were found. So Tested-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Changelog: v2: * Fix a WARN in the shmem THP swap path. Thanks Baolin, Yosry, and Barry for the report and the discussion on how to solve it. * Squash the two patches into one. RFC v1: https://lore.kernel.org/all/20240923231142.4155415-1-nphamcs@gmail.com/ The SWAP_MAP_SHMEM state was originally introduced in the commit aaa468653b4a ("swap_info: note SWAP_MAP_SHMEM"), to quickly determine if a swap entry belongs to shmem during swapoff. However, swapoff has since been rewritten drastically in the commit b56a2d8af914 ("mm: rid swapoff of quadratic complexity"). Now having swap count == SWAP_MAP_SHMEM value is basically the same as having swap count == 1, and swap_shmem_alloc() behaves analogously to swap_duplicate() This RFC proposes the removal of this state and the associated helper to simplify the state machine (both mentally and code-wise). We will also have an extra state/special value that can be repurposed (for swap entries that never gets re-duplicated). Another motivation is the new swap abstraction I am currently working on, that would allow for swap/zswap decoupling, swapoff optimization, etc. The fewer states and swap API functions there are, the simpler the conversion will be. Nhat Pham (1): swap: shmem: remove SWAP_MAP_SHMEM include/linux/swap.h | 16 ++++++++-------- mm/shmem.c | 2 +- mm/swapfile.c | 41 +++++++++++++++++++++-------------------- 3 files changed, 30 insertions(+), 29 deletions(-) base-commit: 391cad4424af8bb563e1504c5adaef0155b4abb6