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

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

On 9/29/26 06:06, 天狼 wrote:
> Hi David,
> 

Hi,

>> What is supposed to happen if the process crashes when updating the
>> MAP_SHARED region halfway through?
> 
> The data structure survives an interrupted update through its
> application-level copy-on-write and lock-free concurrency design. A
> file-backed MAP_SHARED mapping preserves the latest userspace writes after
> the process dies, even if they have not yet reached disk, provided the
> kernel remains running.
> 
> This does not depend on preventing writeback. Deferring writeback is purely
> a performance optimization, not a correctness requirement.
> 
>> It would be helpful if the use case + data structure would be explained
>> in a bit more detail.
> 
> The data structure originally used uint32_t offsets instead of pointers to
> reduce pointer overhead. On that basis, we implemented lock-free concurrent
> reads and writes, obtaining crash safety for free at the same time. We use
> a file-backed MAP_SHARED mapping to turn that capability into an actual
> feature that survives process crashes.

Ok, thanks. Just be sure: you really need an actual file on disk. Shared memory
/ shmem / memfd is not sufficient?

>> What exactly is the problem with writeback here? Unnecessary I/O? Is
>> writeback the problem or actual reclaim after writeback?
> 
> Unnecessary I/O. Reclaim after writeback is not the problem I am trying to
> address.

Ok.

> 
> During construction, background writeback can write intermediate contents
> that the application will soon overwrite. Those repeated writes waste disk
> bandwidth. Delaying writeback would avoid that waste where possible; it is
> not required for correctness.

Understood.

> 
>> In a fuse server you can in theory delay the writeback request.
> 
> Thanks for the suggestion. That sounds like a possible way to experiment
> with delayed writeback. The feature I am requesting would make this
> advisory behavior available to applications using ordinary file-backed
> shared mappings.
> 
>> So fadvise would be an option. However, this "defer mode" is really odd.
>> It sounds more like you would want to have a custom policy there [...]
> 
> madvise is not the only option, deferring writeback for the entire file
> would also be acceptable.
> 
> The application only wants to indicate that it is still modifying the data
> and would prefer background writeback to happen later. The kernel would
> retain control over the actual timing. Memory pressure could override the
> hint, and explicit synchronization would keep its normal semantics.
> 
> The hint should also expire automatically when the owning mapping or handle
> is released, including on process exit.

Ok, so while you are updating the large mmap'ed file concurrently, you don't
want writeback to go crazy, because you know that you will modify the memory
immediately anyway.

Let me CC some more people.


-- 
Cheers,

David