Re: [RFC] madvise: best-effort deferred writeback for shared file mappings

["David Hildenbrand (Arm)" <david@kernel.org>]

On 9/28/26 09:07, 天狼 wrote:
> Hello,

Hi,

> 
> I would like to request feedback on a mapping-scoped, best-effort hint
> to defer background writeback while an application is still constructing
> data in a writable MAP_SHARED mapping of a regular disk-backed file.
> This is a feature request, not a patch submission or a benchmark report.
> 
> Motivation
> ----------
> 
> Consider an application building a large data structure, for example
> 10 GiB, through multiple passes that repeatedly modify the same pages.
> After construction, it persists the file and publishes it for other
> processes to mmap and read.

Is it an option to just construct the data using anonymous memory and then
write()'in it once ready in one operation?

Why exactly are you using writable MAP_SHARED mappings?

> 
> Building directly in MAP_SHARED keeps the data in the file's page cache,
> which also serves the consumers. However, background writeback can write
> intermediate contents that subsequent construction passes dirty again.
> The application knows when construction ends, but cannot express that
> knowledge as a mapping-local writeback scheduling hint.
> 
> Building in private memory and then doing buffered writes adds a bulk
> copy into the file's page cache. Direct I/O does not itself populate that
> cache for subsequent file-mapped consumers. A memfd can share the build
> buffer, but requires a separate object for persistence and changes the
> consumer interface. Global dirty/writeback tuning is broader than this
> particular mapping and construction phase.
> 
> Proposed interface and behavior
> -------------------------------
> 
> Tentatively, a pair of madvise operations could express this:
> 
>     madvise(addr, len, MADV_DEFER_WRITEBACK);
>     /* Construct and repeatedly update the shared file mapping. */
>     madvise(addr, len, MADV_ALLOW_WRITEBACK);
>     /* Use existing synchronization calls if durability is required. */
> 
> The names are placeholders for discussion, not existing constants.

I don't think this behavior should be part of madvise. Way too specific.

-- 
Cheers,

David