From: Barry Song <21cnbao@gmail.com>
To: akpm@linux-foundation.org, linux-mm@kvack.org
Cc: baolin.wang@linux.alibaba.com, chrisl@kernel.org,
david@redhat.com, hanchuanhua@oppo.com, hannes@cmpxchg.org,
hch@infradead.org, hughd@google.com, kaleshsingh@google.com,
kasong@tencent.com, linux-kernel@vger.kernel.org,
mhocko@suse.com, minchan@kernel.org, nphamcs@gmail.com,
ryan.roberts@arm.com, ryncsn@gmail.com, senozhatsky@chromium.org,
shakeel.butt@linux.dev, shy828301@gmail.com, surenb@google.com,
v-songbaohua@oppo.com, willy@infradead.org, xiang@kernel.org,
ying.huang@intel.com, yosryahmed@google.com
Subject: [PATCH v9 0/3] mm: enable large folios swap-in support
Date: Mon, 9 Sep 2024 11:21:16 +1200 [thread overview]
Message-ID: <20240908232119.2157-1-21cnbao@gmail.com> (raw)
From: Barry Song <v-songbaohua@oppo.com>
Currently, we support mTHP swapout but not swapin. This means that once mTHP
is swapped out, it will come back as small folios when swapped in. This is
particularly detrimental for devices like Android, where more than half of
the memory is in swap.
The lack of mTHP swapin functionality makes mTHP a showstopper in scenarios
that heavily rely on swap. This patchset introduces mTHP swap-in support.
It starts with synchronous devices similar to zRAM, aiming to benefit as
many users as possible with minimal changes.
-v9:
* cleanup (rename, drop local variable) for patch 1 according to Yosry,
thanks!
* collect Yosry's reviewed-by tags, thanks!
-v8:
https://lore.kernel.org/linux-mm/20240906001047.1245-1-21cnbao@gmail.com/
* fix the conflicts with zeromap(this is also a hotfix to zeromap with a
Fixes tag), reported by Kairui, thanks!
Usama, Yosry, thanks for all your comments during the discussion!
* refine the changelog to add the case Kanchana reported, using Intel
IAA, with mTHP swap-in zRAM read latency can improve 7X. thanks!
* some other code cleanup
-v7:
https://lore.kernel.org/linux-mm/20240821074541.516249-1-hanchuanhua@oppo.com/
* collect Chris's ack tags, thanks!
* adjust the comment and subject,pointed by Christoph.
* make alloc_swap_folio() always charge the folio to fix the problem of charge
failure in memcg when the memory limit is reached(reported and pointed by
Kairui), pointed by Kefeng, Matthew.
-v6:
https://lore.kernel.org/linux-mm/20240802122031.117548-1-21cnbao@gmail.com/
* remove the swapin control added in v5, per Willy, Christoph;
The original reason for adding the swpin_enabled control was primarily
to address concerns for slower devices. Currently, since we only support
fast sync devices, swap-in size is less of a concern.
We’ll gain a clearer understanding of the next steps while more devices
begin to support mTHP swap-in.
* add nr argument in mem_cgroup_swapin_uncharge_swap() instead of adding
new API, Willy;
* swapcache_prepare() and swapcache_clear() large folios support is also
removed as it has been separated per Baolin's request, right now has
been in mm-unstable.
* provide more data in changelog.
-v5:
https://lore.kernel.org/linux-mm/20240726094618.401593-1-21cnbao@gmail.com/
* Add swap-in control policy according to Ying's proposal. Right now only
"always" and "never" are supported, later we can extend to "auto";
* Fix the comment regarding zswap_never_enabled() according to Yosry;
* Filter out unaligned swp entries earlier;
* add mem_cgroup_swapin_uncharge_swap_nr() helper
-v4:
https://lore.kernel.org/linux-mm/20240629111010.230484-1-21cnbao@gmail.com/
Many parts of v3 have been merged into the mm tree with the help on reviewing
from Ryan, David, Ying and Chris etc. Thank you very much!
This is the final part to allocate large folios and map them.
* Use Yosry's zswap_never_enabled(), notice there is a bug. I put the bug fix
in this v4 RFC though it should be fixed in Yosry's patch
* lots of code improvement (drop large stack, hold ptl etc) according
to Yosry's and Ryan's feedback
* rebased on top of the latest mm-unstable and utilized some new helpers
introduced recently.
-v3:
https://lore.kernel.org/linux-mm/20240304081348.197341-1-21cnbao@gmail.com/
* avoid over-writing err in __swap_duplicate_nr, pointed out by Yosry,
thanks!
* fix the issue folio is charged twice for do_swap_page, separating
alloc_anon_folio and alloc_swap_folio as they have many differences
now on
* memcg charing
* clearing allocated folio or not
-v2:
https://lore.kernel.org/linux-mm/20240229003753.134193-1-21cnbao@gmail.com/
* lots of code cleanup according to Chris's comments, thanks!
* collect Chris's ack tags, thanks!
* address David's comment on moving to use folio_add_new_anon_rmap
for !folio_test_anon in do_swap_page, thanks!
* remove the MADV_PAGEOUT patch from this series as Ryan will
intergrate it into swap-out series
* Apply Kairui's work of "mm/swap: fix race when skipping swapcache"
on large folios swap-in as well
* fixed corrupted data(zero-filled data) in two races: zswap and
a part of entries are in swapcache while some others are not
in by checking SWAP_HAS_CACHE while swapping in a large folio
-v1:
https://lore.kernel.org/all/20240118111036.72641-1-21cnbao@gmail.com/#t
Barry Song (2):
mm: Fix swap_read_folio_zeromap() for large folios with partial
zeromap
mm: add nr argument in mem_cgroup_swapin_uncharge_swap() helper to
support large folios
Chuanhua Han (1):
mm: support large folios swap-in for sync io devices
include/linux/memcontrol.h | 5 +-
mm/memcontrol.c | 7 +-
mm/memory.c | 261 +++++++++++++++++++++++++++++++++----
mm/page_io.c | 32 +----
mm/swap.h | 33 +++++
mm/swap_state.c | 2 +-
6 files changed, 282 insertions(+), 58 deletions(-)
--
2.34.1
next reply other threads:[~2024-09-08 23:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-08 23:21 Barry Song [this message]
2024-09-08 23:21 ` [PATCH v9 1/3] mm: Fix swap_read_folio_zeromap() for large folios with partial zeromap Barry Song
2024-09-09 9:58 ` Usama Arif
2024-09-08 23:21 ` [PATCH v9 2/3] mm: add nr argument in mem_cgroup_swapin_uncharge_swap() helper to support large folios Barry Song
2024-09-08 23:21 ` [PATCH v9 3/3] mm: support large folios swap-in for sync io devices Barry Song
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=20240908232119.2157-1-21cnbao@gmail.com \
--to=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=chrisl@kernel.org \
--cc=david@redhat.com \
--cc=hanchuanhua@oppo.com \
--cc=hannes@cmpxchg.org \
--cc=hch@infradead.org \
--cc=hughd@google.com \
--cc=kaleshsingh@google.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=nphamcs@gmail.com \
--cc=ryan.roberts@arm.com \
--cc=ryncsn@gmail.com \
--cc=senozhatsky@chromium.org \
--cc=shakeel.butt@linux.dev \
--cc=shy828301@gmail.com \
--cc=surenb@google.com \
--cc=v-songbaohua@oppo.com \
--cc=willy@infradead.org \
--cc=xiang@kernel.org \
--cc=ying.huang@intel.com \
--cc=yosryahmed@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox