xiang at kernel.org

[Nithurshen Karthikeyan]

Hi Gao and the EROFS community,

Following up on our recent discussions on GitHub and Matrix, I am
formally submitting this RFC to document my baseline profiling and
proposed  architectural changes for the GSoC project: "Multi-threaded
decompression support in fsck.erofs."

I have set up my build environment on both ARM64 and x86 VMs. I
performed a clean baseline run using the Linux 6.7 kernel source tree
(~87k inodes) packed with LZ4HC to stress the decompression path.

The profile confirms a strictly synchronous execution path. While
decompression (LZ4_decompress_safe) accounts for ~34% of the
task-clock cycles, the trace is dominated by ~74% overhead in kernel
system calls (el0_svc), primarily driven by synchronous vfs_write
operations during extraction.

Children    | Self       | Shared Object | Symbol
-------------------------------------------------------------------------
99.96%     | 0.00%   | fsck.erofs         | main
56.53%     | 0.26%   | fsck.erofs         | erofs_verify_inode_data
17.72%     | 0.60%   | fsck.erofs         | z_erofs_decompress
17.06%     | 16.97% | liblz4.so           | LZ4_decompress_safe
73.87%     | 3.50%   | [kernel]            | el0_svc (Syscall Entry)

This validates the need for parallelization. By moving decompression
to a background workqueue, we can overlap compute-intensive decoding
with the high-latency I/O operations, maximizing CPU utilization.

Proposed Approach :
1. Reuse erofs_workqueue from include/erofs/workqueue.h.
2. Modify z_erofs_read_data() in lib/data.c to act as a producer that
packages decompression requests into work tasks rather than blocking.
3. Utilize worker threads to execute the z_erofs_decompress payload in parallel.

I also have a few questions:
- Should I extend erofs_workqueue for per-job error reporting, or
should fsck manage this via a global state?
- How should we implement memory tracking to prevent OOM if the
producer outruns the worker threads?
- Should we implement a reorder buffer for sequential disk commits, or
is per-file atomic writing sufficient for fsck?

I've attached an interactive Flame Graph (baseline_bottleneck.svg) for
visual reference.

Thank you for your time and guidance.

Best regards,
Nithurshen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: baseline_bottleneck.svg
Type: image/svg+xml
Size: 1107997 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20260226/46bc79ed/attachment.svg>