From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Nithurshen Karthikeyan <nithurshen.dev@gmail.com>
Cc: linux-erofs@lists.ozlabs.org, xiang@kernel.org, hsiangkao@alibaba.com
Subject: Re: [PATCH] erofs-utils: fsck: add concurrent extraction and decompression
Date: Fri, 3 Jul 2026 02:20:35 +0800 [thread overview]
Message-ID: <debaf257-7222-402a-a5e1-2ac67f62ab50@linux.alibaba.com> (raw)
In-Reply-To: <CANRYsKjDbs6_FekTRpJeEw124m9D-mQJu-GvvUP2ms8y9uxK=Q@mail.gmail.com>
On 2026/7/2 20:59, Nithurshen Karthikeyan wrote:
> On Thu, 2 Jul, 2026, 18:24 Gao Xiang, <hsiangkao@linux.alibaba.com> wrote:
>
>>
>>
>> On 2026/7/2 16:10, Nithurshen wrote:
>>> This patch introduces a multi-threaded pipeline for fsck.erofs,
>>> combining parallel directory traversal with background pcluster
>>> decompression to significantly reduce extraction time.
>>>
>>> Key architectural changes include:
>>>
>>> - Thread-Safe State: Removes the global dirstack array and
>>> fsckcfg.extract_path. These are replaced with per-task localized
>>> paths and thread-local linked lists to eliminate data races.
>>> - Concurrent Traversal: Refactors erofsfsck_dirent_iter to allocate
>>> task structures and dispatch inode processing to a background
>>> workqueue (z_erofs_mt_wq).
>>> - Asynchronous Decompression: Introduces z_erofs_mt_read_ctx to
>>> batch pcluster reads and decouple decompression from main I/O.
>>> Limits batch size dynamically (32 for LZ4, 8 for compute-heavy
>>> algorithms) to balance CPU cache hits and memory overhead.
>>> - Memory & Deadlock Safety: Implements inline backpressure during
>>> directory iteration. If pending inodes exceed workqueue capacity,
>>> execution falls back to synchronous processing to prevent
>>> recursive thread-pool starvation and unbounded memory growth.
>>> - Synchronization Primitives: Adds portable condition variable
>>> wrappers (erofs_cond_t) to ensure the main thread safely waits
>>> for all pending background inodes before exiting.
>>>
>>> Signed-off-by: Nithurshen <nithurshen.dev@gmail.com>
>>
>> What's the relationship with the previous two patches?
>>
>
> I made then into one atomic patch, since you wanted them merged at once.
Nope, I didn't want that, I suggested you benchmark each patch.
But it doesn't mean the patches should be merged.
The merge meant merging commits to erofs-utils.
Thanks,
Gao Xiang
>
> Thanks,
> Nithurshen
>
> Thanks,
>> Gao Xiang
>>
>
prev parent reply other threads:[~2026-07-02 18:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 8:10 [PATCH] erofs-utils: fsck: add concurrent extraction and decompression Nithurshen
2026-07-02 12:54 ` Gao Xiang
2026-07-02 12:59 ` Nithurshen Karthikeyan
2026-07-02 18:20 ` 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=debaf257-7222-402a-a5e1-2ac67f62ab50@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=hsiangkao@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