From: Yue Hu <zbestahu@gmail.com>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: Chunhai Guo <guochunhai@vivo.com>,
huyue2@coolpad.com, linux-erofs@lists.ozlabs.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] erofs: relaxed temporary buffers allocation on readahead
Date: Sat, 27 Jan 2024 09:49:48 +0800 [thread overview]
Message-ID: <20240127094948.000024ad.zbestahu@gmail.com> (raw)
In-Reply-To: <20240126140142.201718-1-hsiangkao@linux.alibaba.com>
On Fri, 26 Jan 2024 22:01:42 +0800
Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> From: Chunhai Guo <guochunhai@vivo.com>
>
> Even with inplace decompression, sometimes very few temporary buffers
> may be still needed for a single decompression shot (e.g. 16 pages for
> 64k sliding window or 4 pages for 16k sliding window). In low-memory
> scenarios, it would be better to try to allocate with GFP_NOWAIT on
> readahead first. That can help reduce the time spent on page allocation
> under durative memory pressure.
>
> Here are detailed performance numbers under multi-app launch benchmark
> workload [1] on ARM64 Android devices (8-core CPU and 8GB of memory)
> running a 5.15 LTS kernel with EROFS of 4k pclusters:
>
> +----------------------------------------------+
> | LZ4 | vanilla | patched | diff |
> |----------------+---------+---------+---------|
> | Average (ms) | 3364 | 2684 | -20.21% | [64k sliding window]
> |----------------+---------+---------+---------|
> | Average (ms) | 2079 | 1610 | -22.56% | [16k sliding window]
> +----------------------------------------------+
>
> The total size of system images for 4k pclusters is almost unchanged:
> (64k sliding window) 9,117,044 KB
> (16k sliding window) 9,113,096 KB
>
> Therefore, in addition to switch the sliding window from 64k to 16k,
> after applying this patch, it can eventually save 52.14% (3364 -> 1610)
> on average with no memory reservation. That is particularly useful for
> embedded devices with limited resources.
>
> [1] https://lore.kernel.org/r/20240109074143.4138783-1-guochunhai@vivo.com
>
> Suggested-by: Gao Xiang <xiang@kernel.org>
> Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Yue Hu <huyue2@coolpad.com>
WARNING: multiple messages have this Message-ID (diff)
From: Yue Hu <zbestahu@gmail.com>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: linux-erofs@lists.ozlabs.org, LKML <linux-kernel@vger.kernel.org>,
Chunhai Guo <guochunhai@vivo.com>, Gao Xiang <xiang@kernel.org>,
huyue2@coolpad.com
Subject: Re: [PATCH v4] erofs: relaxed temporary buffers allocation on readahead
Date: Sat, 27 Jan 2024 09:49:48 +0800 [thread overview]
Message-ID: <20240127094948.000024ad.zbestahu@gmail.com> (raw)
In-Reply-To: <20240126140142.201718-1-hsiangkao@linux.alibaba.com>
On Fri, 26 Jan 2024 22:01:42 +0800
Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> From: Chunhai Guo <guochunhai@vivo.com>
>
> Even with inplace decompression, sometimes very few temporary buffers
> may be still needed for a single decompression shot (e.g. 16 pages for
> 64k sliding window or 4 pages for 16k sliding window). In low-memory
> scenarios, it would be better to try to allocate with GFP_NOWAIT on
> readahead first. That can help reduce the time spent on page allocation
> under durative memory pressure.
>
> Here are detailed performance numbers under multi-app launch benchmark
> workload [1] on ARM64 Android devices (8-core CPU and 8GB of memory)
> running a 5.15 LTS kernel with EROFS of 4k pclusters:
>
> +----------------------------------------------+
> | LZ4 | vanilla | patched | diff |
> |----------------+---------+---------+---------|
> | Average (ms) | 3364 | 2684 | -20.21% | [64k sliding window]
> |----------------+---------+---------+---------|
> | Average (ms) | 2079 | 1610 | -22.56% | [16k sliding window]
> +----------------------------------------------+
>
> The total size of system images for 4k pclusters is almost unchanged:
> (64k sliding window) 9,117,044 KB
> (16k sliding window) 9,113,096 KB
>
> Therefore, in addition to switch the sliding window from 64k to 16k,
> after applying this patch, it can eventually save 52.14% (3364 -> 1610)
> on average with no memory reservation. That is particularly useful for
> embedded devices with limited resources.
>
> [1] https://lore.kernel.org/r/20240109074143.4138783-1-guochunhai@vivo.com
>
> Suggested-by: Gao Xiang <xiang@kernel.org>
> Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Yue Hu <huyue2@coolpad.com>
next prev parent reply other threads:[~2024-01-27 1:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-20 14:55 [PATCH v2] erofs: relaxed temporary buffers allocation on readahead Chunhai Guo via Linux-erofs
2024-01-22 2:07 ` Gao Xiang
2024-01-22 3:49 ` Chunhai Guo via Linux-erofs
2024-01-22 4:37 ` Gao Xiang
2024-01-22 7:42 ` Chunhai Guo via Linux-erofs
2024-01-26 2:41 ` Chunhai Guo via Linux-erofs
2024-01-26 2:47 ` Gao Xiang
2024-01-26 3:42 ` Chunhai Guo via Linux-erofs
2024-01-26 3:49 ` Gao Xiang
2024-01-26 3:56 ` 答复: " Chunhai Guo via Linux-erofs
2024-01-26 5:36 ` [PATCH v3] " Gao Xiang
2024-01-26 5:36 ` Gao Xiang
2024-01-26 10:46 ` Yue Hu
2024-01-26 10:46 ` Yue Hu
2024-01-26 13:30 ` Gao Xiang
2024-01-26 13:30 ` Gao Xiang
2024-01-26 14:01 ` [PATCH v4] " Gao Xiang
2024-01-26 14:01 ` Gao Xiang
2024-01-27 1:49 ` Yue Hu [this message]
2024-01-27 1:49 ` Yue Hu
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=20240127094948.000024ad.zbestahu@gmail.com \
--to=zbestahu@gmail.com \
--cc=guochunhai@vivo.com \
--cc=hsiangkao@linux.alibaba.com \
--cc=huyue2@coolpad.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.