From: Kairui Song <ryncsn@gmail.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Chris Li <chrisl@kernel.org>, Hugh Dickins <hughd@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Matthew Wilcox <willy@infradead.org>,
Michal Hocko <mhocko@suse.com>,
Yosry Ahmed <yosryahmed@google.com>,
David Hildenbrand <david@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 9/9] mm/swap, shmem: use new swapin helper to skip readahead conditionally
Date: Wed, 10 Jan 2024 11:35:32 +0800 [thread overview]
Message-ID: <CAMgjq7CkKZ9-ogkU52xwQ1YRj+-jwt4fpOLhtKkumVc8ky3OFQ@mail.gmail.com> (raw)
In-Reply-To: <871qar9sb2.fsf@yhuang6-desk2.ccr.corp.intel.com>
Huang, Ying <ying.huang@intel.com> 于2024年1月9日周二 10:05写道:
>
> Kairui Song <ryncsn@gmail.com> writes:
>
> > From: Kairui Song <kasong@tencent.com>
> >
> > Currently, shmem uses cluster readahead for all swap backends. Cluster
> > readahead is not a good solution for ramdisk based device (ZRAM) at all.
> >
> > After switching to the new helper, most benchmarks showed a good result:
> >
> > - Single file sequence read:
> > perf stat --repeat 20 dd if=/tmpfs/test of=/dev/null bs=1M count=8192
> > (/tmpfs/test is a zero filled file, using brd as swap, 4G memcg limit)
> > Before: 22.248 +- 0.549
> > After: 22.021 +- 0.684 (-1.1%)
> >
> > - Random read stress test:
> > fio -name=tmpfs --numjobs=16 --directory=/tmpfs \
> > --size=256m --ioengine=mmap --rw=randread --random_distribution=random \
> > --time_based --ramp_time=1m --runtime=5m --group_reporting
> > (using brd as swap, 2G memcg limit)
> >
> > Before: 1818MiB/s
> > After: 1888MiB/s (+3.85%)
> >
> > - Zipf biased random read stress test:
> > fio -name=tmpfs --numjobs=16 --directory=/tmpfs \
> > --size=256m --ioengine=mmap --rw=randread --random_distribution=zipf:1.2 \
> > --time_based --ramp_time=1m --runtime=5m --group_reporting
> > (using brd as swap, 2G memcg limit)
> >
> > Before: 31.1GiB/s
> > After: 32.3GiB/s (+3.86%)
> >
> > So cluster readahead doesn't help much even for single sequence read,
> > and for random stress test, the performance is better without it.
> >
> > Considering both memory and swap device will get more fragmented
> > slowly, and commonly used ZRAM consumes much more CPU than plain
> > ramdisk, false readahead could occur more frequently and waste
> > more CPU. Direct SWAP is cheaper, so use the new helper and skip
> > read ahead for SWP_SYNCHRONOUS_IO device.
>
> It's good to take advantage of swap_direct (no readahead). I also hopes
> we can take advantage of VMA based swapin if shmem is accessed via mmap.
> That appears possible.
Good idea, that should be doable, will update the series.
next prev parent reply other threads:[~2024-01-10 3:35 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-02 17:53 [PATCH v2 0/9] swapin refactor for optimization and unified readahead Kairui Song
2024-01-02 17:53 ` [PATCH v2 1/9] mm/swapfile.c: add back some comment Kairui Song
2024-01-02 17:53 ` [PATCH v2 2/9] mm/swap: move no readahead swapin code to a stand-alone helper Kairui Song
2024-01-04 7:28 ` Huang, Ying
2024-01-05 7:43 ` Kairui Song
2024-01-02 17:53 ` [PATCH v2 3/9] mm/swap: avoid doing extra unlock error checks for direct swapin Kairui Song
2024-01-04 8:10 ` Huang, Ying
2024-01-09 9:38 ` Kairui Song
2024-01-02 17:53 ` [PATCH v2 4/9] mm/swap: always account swapped in page into current memcg Kairui Song
2024-01-05 7:14 ` Huang, Ying
2024-01-05 7:33 ` Kairui Song
2024-01-08 7:44 ` Huang, Ying
2024-01-09 9:42 ` Kairui Song
2024-01-02 17:53 ` [PATCH v2 5/9] mm/swap: introduce swapin_entry for unified readahead policy Kairui Song
2024-01-05 7:28 ` Huang, Ying
2024-01-10 2:42 ` Kairui Song
2024-01-02 17:53 ` [PATCH v2 6/9] mm/swap: handle swapcache lookup in swapin_entry Kairui Song
2024-01-08 8:26 ` Huang, Ying
2024-01-10 2:53 ` Kairui Song
2024-01-15 1:45 ` Huang, Ying
2024-01-15 17:11 ` Kairui Song
2024-01-02 17:53 ` [PATCH v2 7/9] mm/swap: avoid a duplicated swap cache lookup for SWP_SYNCHRONOUS_IO Kairui Song
2024-01-03 12:50 ` kernel test robot
2024-01-02 17:53 ` [PATCH v2 8/9] mm/swap: introduce a helper for swapin without vmfault Kairui Song
2024-01-09 1:08 ` Huang, Ying
2024-01-10 3:32 ` Kairui Song
2024-01-15 1:52 ` Huang, Ying
2024-01-21 18:40 ` Kairui Song
2024-01-22 6:38 ` Huang, Ying
2024-01-22 11:35 ` Kairui Song
2024-01-24 3:31 ` Huang, Ying
2024-01-02 17:53 ` [PATCH v2 9/9] mm/swap, shmem: use new swapin helper to skip readahead conditionally Kairui Song
2024-01-03 11:56 ` kernel test robot
2024-01-03 13:45 ` kernel test robot
2024-01-09 2:03 ` Huang, Ying
2024-01-10 3:35 ` Kairui Song [this message]
2024-01-30 0:39 ` Kairui Song
2024-01-30 2:01 ` Huang, Ying
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=CAMgjq7CkKZ9-ogkU52xwQ1YRj+-jwt4fpOLhtKkumVc8ky3OFQ@mail.gmail.com \
--to=ryncsn@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chrisl@kernel.org \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=willy@infradead.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