From: Hongzhen Luo <hongzhen@linux.alibaba.com>
To: linux-erofs@lists.ozlabs.org, lihongbo22@huawei.com
Cc: linux-kernel@vger.kernel.org, Hongzhen Luo <hongzhen@linux.alibaba.com>
Subject: [PATCH RFC v2 0/2] erofs: introduce page cache share feature
Date: Wed, 31 Jul 2024 16:07:02 +0800 [thread overview]
Message-ID: <20240731080704.678259-1-hongzhen@linux.alibaba.com> (raw)
v2:
- Update the `Implementation` section.
- Update the `Effect` section.
- Add the `Restriction` section.
v1: https://lore.kernel.org/all/20240722065355.1396365-1-hongzhen@linux.alibaba.com/
[Background]
================
Currently, reading files with different paths (or names) but the same
content will consume multiple copies of the page cache, even if the
content of these page caches is the same. For example, reading identical
files (e.g., *.so files) from two different minor versions of container
images will cost multiple copies of the same page cache, since different
containers have different mount points. Therefore, sharing the page cache
for files with the same content can save memory.
[Implementation]
================
During the mkfs phase, file content is hashed and the hash value is
stored in the `trusted.erofs.fingerprint` extended attribute. Inodes of
files with the same `trusted.erofs.fingerprint` are mapped to a list, and
this mapping is accomplished through xarray. When a read request occurs,
one of these inodes that in the list (the first inode in this implementation)
is used to store the actual content. In this way, a single copy of the
selected inode's page cache can serve read requests from several files
mapped to it.
[Effect]
================
I conducted experiments on two aspects across two different minor versions of
container images:
1. reading all files in two different minor versions of container images
2. run workloads or use the default entrypoint within the containers^[1]
Below is the memory usage for reading all files in two different minor
versions of container images:
+-------------------+------------------+-------------+---------------+
| Image | Page Cache Share | Memory (MB) | Memory |
| | | | Reduction (%) |
+-------------------+------------------+-------------+---------------+
| | No | 241 | - |
| redis +------------------+-------------+---------------+
| 7.2.4 & 7.2.5 | Yes | 163 | 33% |
+-------------------+------------------+-------------+---------------+
| | No | 872 | - |
| postgres +------------------+-------------+---------------+
| 16.1 & 16.2 | Yes | 630 | 28% |
+-------------------+------------------+-------------+---------------+
| | No | 2771 | - |
| tensorflow +------------------+-------------+---------------+
| 1.11.0 & 2.11.1 | Yes | 2340 | 16% |
+-------------------+------------------+-------------+---------------+
| | No | 926 | - |
| mysql +------------------+-------------+---------------+
| 8.0.11 & 8.0.12 | Yes | 735 | 21% |
+-------------------+------------------+-------------+---------------+
| | No | 390 | - |
| nginx +------------------+-------------+---------------+
| 7.2.4 & 7.2.5 | Yes | 219 | 44% |
+-------------------+------------------+-------------+---------------+
| tomcat | No | 924 | - |
| 10.1.25 & 10.1.26 +------------------+-------------+---------------+
| | Yes | 474 | 49% |
+-------------------+------------------+-------------+---------------+
Additionally, the table below shows the runtime memory usage of the
container:
+-------------------+------------------+-------------+---------------+
| Image | Page Cache Share | Memory (MB) | Memory |
| | | | Reduction (%) |
+-------------------+------------------+-------------+---------------+
| | No | 35 | - |
| redis +------------------+-------------+---------------+
| 7.2.4 & 7.2.5 | Yes | 28 | 20% |
+-------------------+------------------+-------------+---------------+
| | No | 149 | - |
| postgres +------------------+-------------+---------------+
| 16.1 & 16.2 | Yes | 95 | 37% |
+-------------------+------------------+-------------+---------------+
| | No | 1028 | - |
| tensorflow +------------------+-------------+---------------+
| 1.11.0 & 2.11.1 | Yes | 941 | 9% |
+-------------------+------------------+-------------+---------------+
| | No | 155 | - |
| mysql +------------------+-------------+---------------+
| 8.0.11 & 8.0.12 | Yes | 139 | 11% |
+-------------------+------------------+-------------+---------------+
| | No | 25 | - |
| nginx +------------------+-------------+---------------+
| 7.2.4 & 7.2.5 | Yes | 20 | 23% |
+-------------------+------------------+-------------+---------------+
| tomcat | No | 186 | - |
| 10.1.25 & 10.1.26 +------------------+-------------+---------------+
| | Yes | 98 | 48% |
+-------------------+------------------+-------------+---------------+
It can be observed that when reading all the files in the image, the reduced
memory usage varies from 16% to 49%, depending on the specific image.
Additionally, the container's runtime memory usage reduction ranges from 9%
to 48%.
[1] Below are the workload for these images:
- redis: redis-benchmark
- postgres: sysbench
- tensorflow: app.py of tensorflow.python.platform
- mysql: sysbench
- nginx: wrk
- tomcat: default entrypoint
[Restriction]
================
Currently, this feature only supports reading uncompressed files. It do not
support:
- over fscache
- compression
The upcoming updates will expand the range of support to these.
Hongzhen Luo (2):
erofs: introduce page cache share feature
erofs: apply the page cache share feature
fs/erofs/Kconfig | 10 ++
fs/erofs/Makefile | 1 +
fs/erofs/inode.c | 23 +++++
fs/erofs/internal.h | 8 ++
fs/erofs/pagecache_share.c | 189 +++++++++++++++++++++++++++++++++++++
fs/erofs/pagecache_share.h | 15 +++
fs/erofs/super.c | 23 +++++
7 files changed, 269 insertions(+)
create mode 100644 fs/erofs/pagecache_share.c
create mode 100644 fs/erofs/pagecache_share.h
--
2.43.5
next reply other threads:[~2024-07-31 8:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-31 8:07 Hongzhen Luo [this message]
2024-07-31 8:07 ` [PATCH RFC v2 1/2] " Hongzhen Luo
2024-08-01 12:56 ` Hongbo Li
2024-08-02 4:47 ` Hongzhen Luo
2024-07-31 8:07 ` [PATCH RFC v2 2/2] erofs: apply the " Hongzhen Luo
2024-08-01 12:43 ` Hongbo Li
2024-08-02 4:50 ` Hongzhen Luo
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=20240731080704.678259-1-hongzhen@linux.alibaba.com \
--to=hongzhen@linux.alibaba.com \
--cc=lihongbo22@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®