From: "Huang, Ying" <ying.huang@intel.com>
To: Barry Song <21cnbao@gmail.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
baolin.wang@linux.alibaba.com, chrisl@kernel.org,
david@redhat.com, hanchuanhua@oppo.com, hannes@cmpxchg.org,
hughd@google.com, kasong@tencent.com, ryan.roberts@arm.com,
surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org,
xiang@kernel.org, yosryahmed@google.com, yuzhao@google.com,
ziy@nvidia.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] mm: swap: introduce swap_free_nr() for batched swap_free()
Date: Tue, 16 Apr 2024 11:11:51 +0800 [thread overview]
Message-ID: <87ttk20zns.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <CAGsJ_4yim-PQW0JBjZD8dpGBG3FQm=xZb1V51+Nr37nJEwEPzA@mail.gmail.com> (Barry Song's message of "Tue, 16 Apr 2024 14:08:50 +1200")
Barry Song <21cnbao@gmail.com> writes:
> On Tue, Apr 16, 2024 at 1:42 PM Huang, Ying <ying.huang@intel.com> wrote:
>>
>> Barry Song <21cnbao@gmail.com> writes:
>>
>> > On Mon, Apr 15, 2024 at 8:53 PM Huang, Ying <ying.huang@intel.com> wrote:
>> >>
>> >> Barry Song <21cnbao@gmail.com> writes:
>> >>
>> >> > On Mon, Apr 15, 2024 at 8:21 PM Huang, Ying <ying.huang@intel.com> wrote:
>> >> >>
>> >> >> Barry Song <21cnbao@gmail.com> writes:
>> >> >>
>> >> >> > On Mon, Apr 15, 2024 at 6:19 PM Huang, Ying <ying.huang@intel.com> wrote:
>> >> >> >>
>> >> >> >> Barry Song <21cnbao@gmail.com> writes:
>> >> >> >>
>> >> >> >> > From: Chuanhua Han <hanchuanhua@oppo.com>
>> >> >> >> >
>> >> >> >> > While swapping in a large folio, we need to free swaps related to the whole
>> >> >> >> > folio. To avoid frequently acquiring and releasing swap locks, it is better
>> >> >> >> > to introduce an API for batched free.
>> >> >> >> >
>> >> >> >> > Signed-off-by: Chuanhua Han <hanchuanhua@oppo.com>
>> >> >> >> > Co-developed-by: Barry Song <v-songbaohua@oppo.com>
>> >> >> >> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>
>> >> >> >> > ---
>> >> >> >> > include/linux/swap.h | 5 +++++
>> >> >> >> > mm/swapfile.c | 51 ++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >> > 2 files changed, 56 insertions(+)
>> >> >> >> >
>> >> >> >> > diff --git a/include/linux/swap.h b/include/linux/swap.h
>> >> >> >> > index 11c53692f65f..b7a107e983b8 100644
>> >> >> >> > --- a/include/linux/swap.h
>> >> >> >> > +++ b/include/linux/swap.h
>> >> >> >> > @@ -483,6 +483,7 @@ extern void swap_shmem_alloc(swp_entry_t);
>> >> >> >> > extern int swap_duplicate(swp_entry_t);
>> >> >> >> > extern int swapcache_prepare(swp_entry_t);
>> >> >> >> > extern void swap_free(swp_entry_t);
>> >> >> >> > +extern void swap_free_nr(swp_entry_t entry, int nr_pages);
>> >> >> >> > extern void swapcache_free_entries(swp_entry_t *entries, int n);
>> >> >> >> > extern void free_swap_and_cache_nr(swp_entry_t entry, int nr);
>> >> >> >> > int swap_type_of(dev_t device, sector_t offset);
>> >> >> >> > @@ -564,6 +565,10 @@ static inline void swap_free(swp_entry_t swp)
>> >> >> >> > {
>> >> >> >> > }
>> >> >> >> >
>> >> >> >> > +void swap_free_nr(swp_entry_t entry, int nr_pages)
>> >> >> >> > +{
>> >> >> >> > +}
>> >> >> >> > +
>> >> >> >> > static inline void put_swap_folio(struct folio *folio, swp_entry_t swp)
>> >> >> >> > {
>> >> >> >> > }
>> >> >> >> > diff --git a/mm/swapfile.c b/mm/swapfile.c
>> >> >> >> > index 28642c188c93..f4c65aeb088d 100644
>> >> >> >> > --- a/mm/swapfile.c
>> >> >> >> > +++ b/mm/swapfile.c
>> >> >> >> > @@ -1356,6 +1356,57 @@ void swap_free(swp_entry_t entry)
>> >> >> >> > __swap_entry_free(p, entry);
>> >> >> >> > }
>> >> >> >> >
>> >> >> >> > +/*
>> >> >> >> > + * Free up the maximum number of swap entries at once to limit the
>> >> >> >> > + * maximum kernel stack usage.
>> >> >> >> > + */
>> >> >> >> > +#define SWAP_BATCH_NR (SWAPFILE_CLUSTER > 512 ? 512 : SWAPFILE_CLUSTER)
>> >> >> >> > +
>> >> >> >> > +/*
>> >> >> >> > + * Called after swapping in a large folio,
>> >> >> >>
>> >> >> >> IMHO, it's not good to document the caller in the function definition.
>> >> >> >> Because this will discourage function reusing.
>> >> >> >
>> >> >> > ok. right now there is only one user that is why it is added. but i agree
>> >> >> > we can actually remove this.
>> >> >> >
>> >> >> >>
>> >> >> >> > batched free swap entries
>> >> >> >> > + * for this large folio, entry should be for the first subpage and
>> >> >> >> > + * its offset is aligned with nr_pages
>> >> >> >>
>> >> >> >> Why do we need this?
>> >> >> >
>> >> >> > This is a fundamental requirement for the existing kernel, folio's
>> >> >> > swap offset is naturally aligned from the first moment add_to_swap
>> >> >> > to add swapcache's xa. so this comment is describing the existing
>> >> >> > fact. In the future, if we want to support swap-out folio to discontiguous
>> >> >> > and not-aligned offsets, we can't pass entry as the parameter, we should
>> >> >> > instead pass ptep or another different data struct which can connect
>> >> >> > multiple discontiguous swap offsets.
>> >> >> >
>> >> >> > I feel like we only need "for this large folio, entry should be for
>> >> >> > the first subpage" and drop "and its offset is aligned with nr_pages",
>> >> >> > the latter is not important to this context at all.
>> >> >>
>> >> >> IIUC, all these are requirements of the only caller now, not the
>> >> >> function itself. If only part of the all swap entries of a mTHP are
>> >> >> called with swap_free_nr(), can swap_free_nr() still do its work? If
>> >> >> so, why not make swap_free_nr() as general as possible?
>> >> >
>> >> > right , i believe we can make swap_free_nr() as general as possible.
>> >> >
>> >> >>
>> >> >> >>
>> >> >> >> > + */
>> >> >> >> > +void swap_free_nr(swp_entry_t entry, int nr_pages)
>> >> >> >> > +{
>> >> >> >> > + int i, j;
>> >> >> >> > + struct swap_cluster_info *ci;
>> >> >> >> > + struct swap_info_struct *p;
>> >> >> >> > + unsigned int type = swp_type(entry);
>> >> >> >> > + unsigned long offset = swp_offset(entry);
>> >> >> >> > + int batch_nr, remain_nr;
>> >> >> >> > + DECLARE_BITMAP(usage, SWAP_BATCH_NR) = { 0 };
>> >> >> >> > +
>> >> >> >> > + /* all swap entries are within a cluster for mTHP */
>> >> >> >> > + VM_BUG_ON(offset % SWAPFILE_CLUSTER + nr_pages > SWAPFILE_CLUSTER);
>> >> >> >> > +
>> >> >> >> > + if (nr_pages == 1) {
>> >> >> >> > + swap_free(entry);
>> >> >> >> > + return;
>> >> >> >> > + }
>> >> >> >>
>> >> >> >> Is it possible to unify swap_free() and swap_free_nr() into one function
>> >> >> >> with acceptable performance? IIUC, the general rule in mTHP effort is
>> >> >> >> to avoid duplicate functions between mTHP and normal small folio.
>> >> >> >> Right?
>> >> >> >
>> >> >> > I don't see why.
>> >> >>
>> >> >> Because duplicated implementation are hard to maintain in the long term.
>> >> >
>> >> > sorry, i actually meant "I don't see why not", for some reason, the "not"
>> >> > was missed. Obviously I meant "why not", there was a "but" after it :-)
>> >> >
>> >> >>
>> >> >> > but we have lots of places calling swap_free(), we may
>> >> >> > have to change them all to call swap_free_nr(entry, 1); the other possible
>> >> >> > way is making swap_free() a wrapper of swap_free_nr() always using
>> >> >> > 1 as the argument. In both cases, we are changing the semantics of
>> >> >> > swap_free_nr() to partially freeing large folio cases and have to drop
>> >> >> > "entry should be for the first subpage" then.
>> >> >> >
>> >> >> > Right now, the semantics is
>> >> >> > * swap_free_nr() for an entire large folio;
>> >> >> > * swap_free() for one entry of either a large folio or a small folio
>> >> >>
>> >> >> As above, I don't think the these semantics are important for
>> >> >> swap_free_nr() implementation.
>> >> >
>> >> > right. I agree. If we are ready to change all those callers, nothing
>> >> > can stop us from removing swap_free().
>> >> >
>> >> >>
>> >> >> >>
>> >> >> >> > +
>> >> >> >> > + remain_nr = nr_pages;
>> >> >> >> > + p = _swap_info_get(entry);
>> >> >> >> > + if (p) {
>> >> >> >> > + for (i = 0; i < nr_pages; i += batch_nr) {
>> >> >> >> > + batch_nr = min_t(int, SWAP_BATCH_NR, remain_nr);
>> >> >> >> > +
>> >> >> >> > + ci = lock_cluster_or_swap_info(p, offset);
>> >> >> >> > + for (j = 0; j < batch_nr; j++) {
>> >> >> >> > + if (__swap_entry_free_locked(p, offset + i * SWAP_BATCH_NR + j, 1))
>> >> >> >> > + __bitmap_set(usage, j, 1);
>> >> >> >> > + }
>> >> >> >> > + unlock_cluster_or_swap_info(p, ci);
>> >> >> >> > +
>> >> >> >> > + for_each_clear_bit(j, usage, batch_nr)
>> >> >> >> > + free_swap_slot(swp_entry(type, offset + i * SWAP_BATCH_NR + j));
>> >> >> >> > +
>> >> >> >> > + bitmap_clear(usage, 0, SWAP_BATCH_NR);
>> >> >> >> > + remain_nr -= batch_nr;
>> >> >> >> > + }
>> >> >> >> > + }
>> >> >> >> > +}
>> >> >> >> > +
>> >> >> >> > /*
>> >> >> >> > * Called after dropping swapcache to decrease refcnt to swap entries.
>> >> >> >> > */
>> >> >> >>
>> >> >> >> put_swap_folio() implements batching in another method. Do you think
>> >> >> >> that it's good to use the batching method in that function here? It
>> >> >> >> avoids to use bitmap operations and stack space.
>> >> >> >
>> >> >> > Chuanhua has strictly limited the maximum stack usage to several
>> >> >> > unsigned long,
>> >> >>
>> >> >> 512 / 8 = 64 bytes.
>> >> >>
>> >> >> So, not trivial.
>> >> >>
>> >> >> > so this should be safe. on the other hand, i believe this
>> >> >> > implementation is more efficient, as put_swap_folio() might lock/
>> >> >> > unlock much more often whenever __swap_entry_free_locked returns
>> >> >> > 0.
>> >> >>
>> >> >> There are 2 most common use cases,
>> >> >>
>> >> >> - all swap entries have usage count == 0
>> >> >> - all swap entries have usage count != 0
>> >> >>
>> >> >> In both cases, we only need to lock/unlock once. In fact, I didn't
>> >> >> find possible use cases other than above.
>> >> >
>> >> > i guess the point is free_swap_slot() shouldn't be called within
>> >> > lock_cluster_or_swap_info? so when we are freeing nr_pages slots,
>> >> > we'll have to unlock and lock nr_pages times? and this is the most
>> >> > common scenario.
>> >>
>> >> No. In put_swap_folio(), free_entries is either SWAPFILE_CLUSTER (that
>> >> is, nr_pages) or 0. These are the most common cases.
>> >>
>> >
>> > i am actually talking about the below code path,
>> >
>> > void put_swap_folio(struct folio *folio, swp_entry_t entry)
>> > {
>> > ...
>> >
>> > ci = lock_cluster_or_swap_info(si, offset);
>> > ...
>> > for (i = 0; i < size; i++, entry.val++) {
>> > if (!__swap_entry_free_locked(si, offset + i, SWAP_HAS_CACHE)) {
>> > unlock_cluster_or_swap_info(si, ci);
>> > free_swap_slot(entry);
>> > if (i == size - 1)
>> > return;
>> > lock_cluster_or_swap_info(si, offset);
>> > }
>> > }
>> > unlock_cluster_or_swap_info(si, ci);
>> > }
>> >
>> > but i guess you are talking about the below code path:
>> >
>> > void put_swap_folio(struct folio *folio, swp_entry_t entry)
>> > {
>> > ...
>> >
>> > ci = lock_cluster_or_swap_info(si, offset);
>> > if (size == SWAPFILE_CLUSTER) {
>> > map = si->swap_map + offset;
>> > for (i = 0; i < SWAPFILE_CLUSTER; i++) {
>> > val = map[i];
>> > VM_BUG_ON(!(val & SWAP_HAS_CACHE));
>> > if (val == SWAP_HAS_CACHE)
>> > free_entries++;
>> > }
>> > if (free_entries == SWAPFILE_CLUSTER) {
>> > unlock_cluster_or_swap_info(si, ci);
>> > spin_lock(&si->lock);
>> > mem_cgroup_uncharge_swap(entry, SWAPFILE_CLUSTER);
>> > swap_free_cluster(si, idx);
>> > spin_unlock(&si->lock);
>> > return;
>> > }
>> > }
>> > }
>>
>> I am talking about both code paths. In 2 most common cases,
>> __swap_entry_free_locked() will return 0 or !0 for all entries in range.
>
> I grasp your point, but if conditions involving 0 or non-0 values fail, we'll
> end up repeatedly unlocking and locking. Picture a scenario with a large
> folio shared by multiple processes. One process might unmap a portion
> while another still holds an entire mapping to it. This could lead to situations
> where free_entries doesn't equal 0 and free_entries doesn't equal
> nr_pages, resulting in multiple unlock and lock operations.
This is impossible in current caller, because the folio is in the swap
cache. But if we move the change to __swap_entry_free_nr(), we may run
into this situation.
> Chuanhua has invested significant effort in following Ryan's suggestion
> for the current approach, which generally handles all cases, especially
> partial unmapping. Additionally, the widespread use of swap_free_nr()
> as you suggested across various scenarios is noteworthy.
>
> Unless there's evidence indicating performance issues or bugs, I believe
> the current approach remains preferable.
TBH, I don't like the large stack space usage (64 bytes). How about use
a "unsigned long" as bitmap? Then, we use much less stack space, use
bitmap == 0 and bitmap == (unsigned long)(-1) to check the most common
use cases. And, we have enough batching.
>>
>> > we are mTHP, so we can't assume our size is SWAPFILE_CLUSTER?
>> > or you want to check free_entries == "1 << swap_entry_order(folio_order(folio))"
>> > instead of SWAPFILE_CLUSTER for the "for (i = 0; i < size; i++, entry.val++)"
>> > path?
>>
>> Just replace SWAPFILE_CLUSTER with "nr_pages" in your code.
>>
>> >
>> >> >>
>> >> >> And, we should add batching in __swap_entry_free(). That will help
>> >> >> free_swap_and_cache_nr() too.
>> >
>> > Chris Li and I actually discussed it before, while I completely
>> > agree this can be batched. but i'd like to defer this as an incremental
>> > patchset later to keep this swapcache-refault small.
>>
>> OK.
>>
>> >>
>> >> Please consider this too.
--
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2024-04-16 3:13 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 8:26 [PATCH v2 0/5] large folios swap-in: handle refault cases first Barry Song
2024-04-09 8:26 ` [PATCH v2 1/5] mm: swap: introduce swap_free_nr() for batched swap_free() Barry Song
2024-04-10 23:37 ` SeongJae Park
2024-04-11 1:27 ` Barry Song
2024-04-11 14:30 ` Ryan Roberts
2024-04-12 2:07 ` Chuanhua Han
2024-04-12 11:28 ` Ryan Roberts
2024-04-12 11:38 ` Chuanhua Han
2024-04-15 6:17 ` Huang, Ying
2024-04-15 7:04 ` Barry Song
2024-04-15 8:06 ` Barry Song
2024-04-15 8:19 ` Huang, Ying
2024-04-15 8:34 ` Barry Song
2024-04-15 8:51 ` Huang, Ying
2024-04-15 9:01 ` Barry Song
2024-04-16 1:40 ` Huang, Ying
2024-04-16 2:08 ` Barry Song
2024-04-16 3:11 ` Huang, Ying [this message]
2024-04-16 4:32 ` Barry Song
2024-04-17 0:32 ` Huang, Ying
2024-04-17 1:35 ` Barry Song
2024-04-18 5:27 ` Barry Song
2024-04-18 8:55 ` Huang, Ying
2024-04-18 9:14 ` Barry Song
2024-05-02 23:05 ` Barry Song
2024-04-09 8:26 ` [PATCH v2 2/5] mm: swap: make should_try_to_free_swap() support large-folio Barry Song
2024-04-15 7:11 ` Huang, Ying
2024-04-09 8:26 ` [PATCH v2 3/5] mm: swap_pte_batch: add an output argument to reture if all swap entries are exclusive Barry Song
2024-04-11 14:54 ` Ryan Roberts
2024-04-11 15:00 ` David Hildenbrand
2024-04-11 15:36 ` Ryan Roberts
2024-04-09 8:26 ` [PATCH v2 4/5] mm: swap: entirely map large folios found in swapcache Barry Song
2024-04-11 15:33 ` Ryan Roberts
2024-04-11 23:30 ` Barry Song
2024-04-12 11:31 ` Ryan Roberts
2024-04-15 8:37 ` Huang, Ying
2024-04-15 8:53 ` Barry Song
2024-04-16 2:25 ` Huang, Ying
2024-04-16 2:36 ` Barry Song
2024-04-16 2:39 ` Huang, Ying
2024-04-16 2:52 ` Barry Song
2024-04-16 3:17 ` Huang, Ying
2024-04-16 4:40 ` Barry Song
2024-04-18 9:55 ` Barry Song
2024-04-09 8:26 ` [PATCH v2 5/5] mm: add per-order mTHP swpin_refault counter Barry Song
2024-04-10 23:15 ` SeongJae Park
2024-04-11 1:46 ` Barry Song
2024-04-11 16:14 ` SeongJae Park
2024-04-11 15:53 ` Ryan Roberts
2024-04-11 23:01 ` Barry Song
2024-04-17 0:45 ` Huang, Ying
2024-04-17 1:16 ` Barry Song
2024-04-17 1:38 ` Huang, Ying
2024-04-17 1:48 ` 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=87ttk20zns.fsf@yhuang6-desk2.ccr.corp.intel.com \
--to=ying.huang@intel.com \
--cc=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=hughd@google.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=v-songbaohua@oppo.com \
--cc=willy@infradead.org \
--cc=xiang@kernel.org \
--cc=yosryahmed@google.com \
--cc=yuzhao@google.com \
--cc=ziy@nvidia.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