From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Chunhai Guo <guochunhai@vivo.com>, "xiang@kernel.org" <xiang@kernel.org>
Cc: "linux-erofs@lists.ozlabs.org" <linux-erofs@lists.ozlabs.org>,
"huyue2@coolpad.com" <huyue2@coolpad.com>
Subject: Re: [PATCH v2] erofs: add a global page pool for lz4 decompression
Date: Mon, 22 Jan 2024 12:41:17 +0800 [thread overview]
Message-ID: <df584384-b672-4434-8d10-e488b0d91a69@linux.alibaba.com> (raw)
In-Reply-To: <69711d55-f7a2-420b-9ba8-fa2921f66a4c@vivo.com>
Hi Chunhai,
On 2024/1/12 09:58, Chunhai Guo wrote:
> On 2024/1/10 14:45, Chunhai Guo wrote:
>> On 2024/1/9 21:08, Gao Xiang wrote:
>>> [你通常不会收到来自 hsiangkao@linux.alibaba.com 的电子邮件。请访问
>>> https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要]
>>>
>>> Hi Chunhai,
>>>
>>> On 2024/1/9 15:41, Chunhai Guo wrote:
>>>> Using a global page pool for LZ4 decompression significantly reduces
>>>> the
>>>> time spent on page allocation in low memory scenarios.
>>>>
>>>> The table below shows the reduction in time spent on page allocation
>>>> for
>>>> LZ4 decompression when using a global page pool. The results were
>>>> obtained from multi-app launch benchmarks on ARM64 Android devices
>>>> running the 5.15 kernel with an 8-core CPU and 8GB of memory. In the
>>>> benchmark, we launched 16 frequently-used apps, and the camera app was
>>>> the last one in each round. The data in the table is the average
>>>> time of
>>>> camera app for each round.
>>>> After using the page pool, there was an average improvement of 150ms in
>>>> the launch time of the camera app, which was obtained from systrace
>>>> log.
>>>> +--------------+---------------+--------------+---------+
>>>> | | w/o page pool | w/ page pool | diff |
>>>> +--------------+---------------+--------------+---------+
>>>> | Average (ms) | 3434 | 21 | -99.38% |
>>>> +--------------+---------------+--------------+---------+
>>>>
>>>> Based on the benchmark logs, 64 pages are sufficient for 95% of
>>>> scenarios. This value can be adjusted from the module parameter. The
>>>> default value is 0.
>>>>
>>>> This patch currently only supports the LZ4 decompressor, other
>>>> decompressors will be supported in the next step.
>>>>
>>>> Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
>>>
>>> This patch looks good to me, yet we're in the merge window for v6.8.
>>> I will address it after -rc1 is out since no stable tag these days.
>>>
>>> Also it would be better to add some results of changing max_distance
>>> if you have more time to test.
>>
>> OK. I will reply to this email when the experiment is finished.
>
> Dear Xiang,
>
> The experiment is done and table below shows the results. We can find
> that a 16k sliding window reduces 38.2% of time used in page allocation
> for LZ4 decompression compared to a 64k sliding window. However, using a
> global page pool is still far better than both of them.
>
> +--------------+---------------+--------------+---------+
> | | 64k window | 16k window | diff |
> +--------------+---------------+--------------+---------+
> | Average (ms) | 3364 | 2079 | -38.2% |
> +--------------+---------------+--------------+---------+
>
> Thanks,
Let's rebase this onto
commit ("erofs: relaxed temporary buffers allocation on readahead")
I will merge these after the rebase patch is received.
Thanks,
Gao Xiang
prev parent reply other threads:[~2024-01-22 4:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-09 7:41 [PATCH v2] erofs: add a global page pool for lz4 decompression Chunhai Guo via Linux-erofs
2024-01-09 13:08 ` Gao Xiang
2024-01-10 6:45 ` Chunhai Guo via Linux-erofs
2024-01-12 1:58 ` Chunhai Guo via Linux-erofs
2024-01-22 4:41 ` Gao Xiang [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=df584384-b672-4434-8d10-e488b0d91a69@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=guochunhai@vivo.com \
--cc=huyue2@coolpad.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=xiang@kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).