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

[Wenjie Qi <qwjhust@gmail.com>]

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?