From: Kairui Song <ryncsn@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, Chris Li <chrisl@kernel.org>,
Barry Song <v-songbaohua@oppo.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Hugh Dickins <hughd@google.com>,
Yosry Ahmed <yosryahmed@google.com>,
"Huang, Ying" <ying.huang@intel.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Nhat Pham <nphamcs@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/13] mm, swap: rework of swap allocator locks
Date: Thu, 24 Oct 2024 01:56:43 +0800 [thread overview]
Message-ID: <CAMgjq7CNm1iFvzmbjMy+J7aruVMhsMW=fdSFgCHCT3MuspsUNw@mail.gmail.com> (raw)
In-Reply-To: <20241023032744.84a6a9f6f5f1e3aa1fe5f0d9@linux-foundation.org>
On Wed, Oct 23, 2024 at 6:27 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 23 Oct 2024 03:24:38 +0800 Kairui Song <ryncsn@gmail.com> wrote:
>
> > After this series, lock contention on si->lock is nearly unobservable
> > with `perf lock` with the same test above :
> >
> > contended total wait max wait avg wait type caller
> > ... snip ...
> > 91 204.62 us 4.51 us 2.25 us spinlock cluster_move+0x2e
> > ... snip ...
> > 47 125.62 us 4.47 us 2.67 us spinlock cluster_move+0x2e
> > ... snip ...
> > 23 63.15 us 3.95 us 2.74 us spinlock cluster_move+0x2e
> > ... snip ...
> > 17 41.26 us 4.58 us 2.43 us spinlock cluster_isolate_lock+0x1d
> > ... snip ...
>
> Were any overall runtime benefits observed?
Yes, see the "Tests" results in the cover letter (summary: up to 50%
build time saved for build linux kernel test when under pressure, with
either mTHP or 4K pages):
time make -j96 / 768M memcg, 4K pages, 10G ZRAM, on Intel 8255C * 2 in VM:
(avg of 4 test run)
Before:
Sys time: 73578.30, Real time: 864.05
After: (-54.7% sys time, -49.3% real time)
Sys time: 33314.76, Real time: 437.67
time make -j96 / 1152M memcg, 64K mTHP, 10G ZRAM, on Intel 8255C * 2 in VM:
(avg of 4 test run)
Before:
Sys time: 74044.85, Real time: 846.51
After: (-51.4% sys time, -47.7% real time, -63.2% mTHP failure)
Sys time: 35958.87, Real time: 442.69
Tests on the host bare metal showed similar results.
There are some other test results I didn't include in the cover letter
for V1 yet and I'm still testing more scenarios, eg. mysql test in 1G
memcg and with 96 workers and ZRAM swap:
before:
transactions: 755630 (6292.11 per sec.)
queries: 12090080 (100673.69 per sec.)
after:
transactions: 1077156 (8972.73 per sec.)
queries: 17234496 (143563.65 per sec.)
~30% faster.
Also the mTHP swap allocation success rate is higher, I can highlight
these changes in V2.
next prev parent reply other threads:[~2024-10-23 17:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-22 19:24 Kairui Song
2024-10-22 19:24 ` [PATCH 01/13] mm, swap: minor clean up for swap entry allocation Kairui Song
2024-10-22 19:24 ` [PATCH 02/13] mm, swap: fold swap_info_get_cont in the only caller Kairui Song
2024-10-22 19:24 ` [PATCH 03/13] mm, swap: remove old allocation path for HDD Kairui Song
2024-10-22 19:24 ` [PATCH 04/13] mm, swap: use cluster lock " Kairui Song
2024-10-22 19:24 ` [PATCH 05/13] mm, swap: clean up device availability check Kairui Song
2024-10-22 19:24 ` [PATCH 06/13] mm, swap: clean up plist removal and adding Kairui Song
2024-10-22 19:24 ` [PATCH 07/13] mm, swap: hold a reference of si during scan and clean up flags Kairui Song
2024-10-22 19:24 ` [PATCH 08/13] mm, swap: use an enum to define all cluster flags and wrap flags changes Kairui Song
2024-10-22 19:24 ` [PATCH 09/13] mm, swap: reduce contention on device lock Kairui Song
2024-10-22 19:24 ` [PATCH 10/13] mm, swap: simplify percpu cluster updating Kairui Song
2024-10-22 19:24 ` [PATCH 11/13] mm, swap: introduce a helper for retrieving cluster from offset Kairui Song
2024-10-22 19:24 ` [PATCH 12/13] mm, swap: use a global swap cluster for non-rotation device Kairui Song
2024-10-22 19:37 ` [PATCH 13/13] mm, swap_slots: remove slot cache for freeing path Kairui Song
2024-10-23 2:24 ` [PATCH 00/13] mm, swap: rework of swap allocator locks Huang, Ying
2024-10-23 18:01 ` Kairui Song
2024-10-24 3:04 ` Huang, Ying
2024-10-24 3:51 ` Kairui Song
2024-10-23 10:27 ` Andrew Morton
2024-10-23 17:56 ` Kairui Song [this message]
2024-10-23 17:59 ` Yosry Ahmed
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='CAMgjq7CNm1iFvzmbjMy+J7aruVMhsMW=fdSFgCHCT3MuspsUNw@mail.gmail.com' \
--to=ryncsn@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chrisl@kernel.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=ryan.roberts@arm.com \
--cc=tim.c.chen@linux.intel.com \
--cc=v-songbaohua@oppo.com \
--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