On 6/4/24 09:36, Jingbo Xu wrote: > > > On 6/4/24 3:27 PM, Miklos Szeredi wrote: >> On Tue, 4 Jun 2024 at 03:57, Jingbo Xu <jefflexu@xxxxxxxxxxxxxxxxx> wrote: >> >>> IIUC, there are two sources that may cause deadlock: >>> 1) the fuse server needs memory allocation when processing FUSE_WRITE >>> requests, which in turn triggers direct memory reclaim, and FUSE >>> writeback then - deadlock here >> >> Yep, see the folio_wait_writeback() call deep in the guts of direct >> reclaim, which sleeps until the PG_writeback flag is cleared. If that >> happens to be triggered by the writeback in question, then that's a >> deadlock. >> >>> 2) a process that trigfgers direct memory reclaim or calls sync(2) may >>> hang there forever, if the fuse server is buggyly or malicious and thus >>> hang there when processing FUSE_WRITE requests >> >> Ah, yes, sync(2) is also an interesting case. We don't want unpriv >> fuse servers to be able to block sync(2), which means that sync(2) >> won't actually guarantee a synchronization of fuse's dirty pages. I >> don't think there's even a theoretical solution to that, but >> apparently nobody cares... > > Okay if the temp page design is unavoidable, then I don't know if there > is any approach (in FUSE or VFS layer) helps page copy offloading. At > least we don't want the writeback performance to be limited by the > single writeback kworker. This is also the initial attempt of this thread. > Offloading it to another thread is just a workaround, though maybe a temporary solution. Back to the background for the copy, so it copies pages to avoid blocking on memory reclaim. With that allocation it in fact increases memory pressure even more. Isn't the right solution to mark those pages as not reclaimable and to avoid blocking on it? Which is what the tmp pages do, just not in beautiful way. Thanks, Bernd
