linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Kairui Song <ryncsn@gmail.com>
Cc: linux-mm <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>,
	 LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 9/9] mm/swap, shmem: use new swapin helper to skip readahead conditionally
Date: Tue, 30 Jan 2024 10:01:22 +0800	[thread overview]
Message-ID: <87h6ivinpp.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <CAMgjq7ByEsYCj+YeQPS8g1tdKeJnwBhFyqPHCWufzLSfGJYr2A@mail.gmail.com> (Kairui Song's message of "Tue, 30 Jan 2024 08:39:34 +0800")

Kairui Song <ryncsn@gmail.com> writes:

> On Wed, Jan 10, 2024 at 11:35 AM Kairui Song <ryncsn@gmail.com> wrote:
>>
>> 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.
>
> Hi Ying,
>
> Turns out it's quite complex to do VMA bases swapin readhead for shmem: VMA
> address / Page Tables doesn't contain swapin entry for shmem. For anon page
> simply read nearby page table is easy and good enough, but for shmem, it's
> stored in the inode mapping so the readahead needs to walk the inode
> mapping instead. That's doable but requires more work to make it actually
> usable. I've sent V3 without this feature, worth another series for this
> readahead extension.

Got it.  Thanks for looking at this.

--
Best Regards,
Huang, Ying


      reply	other threads:[~2024-01-30  2:04 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
2024-01-30  0:39       ` Kairui Song
2024-01-30  2:01         ` Huang, Ying [this message]

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=87h6ivinpp.fsf@yhuang6-desk2.ccr.corp.intel.com \
    --to=ying.huang@intel.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=ryncsn@gmail.com \
    --cc=willy@infradead.org \
    --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