Re: [PATCH v1 00/12] f2fs: introduce metadata cache

[Chao Yu]

Wenjie,

Thanks for sharing the info, I guess we can discuss after we upstream
this serial. :)

On 8/24/26 18:07, Wenjie Qi wrote:
> Hi Chao,
>
> At Xiaomi, we have an out-of-tree F2FS node-cache prototype for mobile
> workloads that retains clean node contents in compressed memory after
> page-cache reclaim.  This is different from this series:
> F2FS_NODE_CACHE is the primary cache and can hold dirty authoritative
> data, while our compressed contents are clean and disposable.
>
> In our mobile workloads, clean F2FS node pages can represent roughly
> 100 MB of uncompressed working-set memory.  We have observed an LZ4
> payload-to-original ratio of about 0.1 for these pages, excluding
> zsmalloc fragmentation, entry metadata, and workspaces.  Node reads are
> also on latency-sensitive paths, while memory pressure can repeatedly
> reclaim and later reread the same node pages from storage.
>
> These are observations from our out-of-tree mobile workloads, not
> benchmark results from this series or current upstream Linux.
>
> If the primary metadata-cache model moves forward, the direction we
> would like to explore is one F2FS_NODE_CACHE slot per NID with mutually
> exclusive clean representations:
>
>      UNCOMPRESSED_CLEAN <-> COMPRESSED_CLEAN
>
> Active, dirty, and writeback entries would stay uncompressed, and a
> slot would not retain stable copies in both forms.  Compression would be
> prepared outside the shrinker and direct-reclaim paths.  Shrinker reclaim
> would continue to discard clean entries without compression, allocation,
> or I/O.
>
> If an optional compressed representation for clean, idle F2FS_NODE_CACHE
> entries fits your intended metadata-cache roadmap, would it make sense to
> discuss the clean-entry state and lifetime contract first, and prototype
> it on top of v2 once the base cache is ready?