From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Nithurshen <nithurshen.dev@gmail.com>, linux-erofs@lists.ozlabs.org
Cc: xiang@kernel.org
Subject: Re: [PATCH v1] fsck.erofs: implement thread-safe global LRU metadata cache
Date: Thu, 11 Jun 2026 17:15:43 +0800 [thread overview]
Message-ID: <423c662c-e8b4-4802-b7bf-34abd71a82ae@linux.alibaba.com> (raw)
In-Reply-To: <20260611083601.81061-1-nithurshen.dev@gmail.com>
On 2026/6/11 16:36, Nithurshen wrote:
> This patch introduces a thread-safe metadata cache to reduce redundant
> I/O and decompression overhead during fsck extraction.
>
> To ensure it remains highly concurrent for worker threads extracting
> pclusters, the cache utilizes a bucketed, rw-semaphore protected
> architecture modeled after the existing fragment cache.
>
> Furthermore, to prevent out-of-memory (OOM) scenarios on exceptionally
> large EROFS images, the cache implements a strict Global Least Recently
> Used (LRU) eviction policy. The maximum cache size is dynamically
> configurable via the new '--cache-size' parameter, which defaults to a
> safe, fixed threshold of 32 MB.
>
> Signed-off-by: Nithurshen <nithurshen.dev@gmail.com>
why `malloc()` will prevent out-of-memory (OOM)?
First, either erofs_read_metadata_nid() or erofs_read_metadata_bdi()
will read file to the page cache; and currently there is no cache.
But you introduce another cache using malloc(), since it increases
the memory overhead, why it prevents out-of-memory (OOM)?
Thanks,
Gao Xiang
next prev parent reply other threads:[~2026-06-11 9:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 8:36 [PATCH v1] fsck.erofs: implement thread-safe global LRU metadata cache Nithurshen
2026-06-11 9:15 ` Gao Xiang [this message]
2026-06-13 10:10 ` Nithurshen
2026-06-15 1:48 ` Gao Xiang
2026-06-15 2:45 ` Nithurshen
2026-06-11 18:46 ` [PATCH v2] " Nithurshen
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=423c662c-e8b4-4802-b7bf-34abd71a82ae@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=nithurshen.dev@gmail.com \
--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