On Tue, 2025-01-07 at 09:34 +0100, David Hildenbrand wrote: > On 06.01.25 19:17, Shakeel Butt wrote: > > On Mon, Jan 06, 2025 at 11:19:42AM +0100, Miklos Szeredi wrote: > > > On Fri, 3 Jan 2025 at 21:31, David Hildenbrand <david@xxxxxxxxxx> wrote: > > > > In any case, having movable pages be turned unmovable due to persistent > > > > writaback is something that must be fixed, not worked around. Likely a > > > > good topic for LSF/MM. > > > > > > Yes, this seems a good cross fs-mm topic. > > > > > > So the issue discussed here is that movable pages used for fuse > > > page-cache cause a problems when memory needs to be compacted. The > > > problem is either that > > > > > > - the page is skipped, leaving the physical memory block unmovable > > > > > > - the compaction is blocked for an unbounded time > > > > > > While the new AS_WRITEBACK_INDETERMINATE could potentially make things > > > worse, the same thing happens on readahead, since the new page can be > > > locked for an indeterminate amount of time, which can also block > > > compaction, right? > > Yes, as memory hotplug + virtio-mem maintainer my bigger concern is > these pages residing in ZONE_MOVABLE / MIGRATE_CMA areas where there > *must not be unmovable pages ever*. Not triggered by an untrusted > source, not triggered by an trusted source. > > It's a violation of core-mm principles. > > Even if we have a timeout of 60s, making things like alloc_contig_page() > wait for that long on writeback is broken and needs to be fixed. > > And the fix is not to skip these pages, that's a workaround. > > I'm hoping I can find an easy way to trigger this also with NFS. > I imagine that you can just open a file and start writing to it, pull the plug on the NFS server, and then issue a fsync or something to ensure some writeback occurs. Any dirty pagecache folios should be stuck in writeback at that point. The NFS client is also very patient about waiting for the server to come back, so it should stay that way indefinitely. > > > > Yes locked pages are unmovable. How much of these locked pages/folios > > can be caused by untrusted fuse server? > > >> > > > What about explicitly opting fuse cache pages out of compaction by > > > allocating them form ZONE_UNMOVABLE? > > > > This can be done but it will change the memory condition of the > > users/workloads/systems where page cache is the majority of the memory > > (i.e. majority of memory will be unmovable) and when such systems are > > overcommitted, weird corner cases will arise (failing high order > > allocations, long term fragmentation etc). In addition the memory > > behind CXL will become unusable for fuse folios. > > Yes. > > > > > IMHO the transient unmovable state of fuse folios due to writeback is > > not an issue if we can show that untrusted fuse server can not cause > > unlimited folios under writeback for arbitrary long time. > > See above, I disagree. > -- Jeff Layton <jlayton@xxxxxxxxxx>
