On 11/11/24 8:05 AM, Jens Axboe wrote: > On 11/11/24 7:08 AM, Jens Axboe wrote: >> On 11/11/24 5:55 AM, Stefan Metzmacher wrote: >>> Hi Jens, >>> >>> I'm wondering about the impact on memory mapped files. >>> >>> Let's say one (or more) process(es) called mmap on a file in order to >>> use the content of the file as persistent shared memory. >>> As far as I understand pages from the page cache are used for this. >>> >>> Now another process uses RWF_UNCACHED for a read of the same file. >>> What happens if the pages are removed from the page cache? >>> Or is the removal deferred based on some refcount? >> >> For mmap, if a given page isn't in page cache, it'll get faulted in. >> Should be fine to have mmap and uncached IO co-exist. If an uncached >> read IO instantiates a page, it'll get reaped when the data has been >> copied. If an uncached IO hits an already existing page (eg mmap faulted >> it in), then it won't get touched. Same thing happens with mixing >> buffered and uncached IO. The latter will only reap parts it >> instantiated to satisfy the operation. That doesn't matter in terms of >> data integrity, only in terms of the policy of uncached leaving things >> alone it didn't create to satisfy the operation. >> >> This is really no different than say using mmap and evicting pages, they >> will just get faulted in if needed. > > Turns out that was nonsense, as per Kiril's comments on the other thread. > For pages that are actually mapped, we'll have to skip the invalidation > as it's not safe to do so. ...and now v3 (just posted) actually does work like I described, it'll co-exist with mmap. -- Jens Axboe