On Tue, Sep 27, 2022 at 7:57 PM John Hubbard <jhubbard@xxxxxxxxxx> wrote: > > On 9/27/22 19:14, Yang Shi wrote: > > IIRC, the writeback may not call generic_writepages. On my ext4 > > filesystem, the writeback call stack looks like: > > > > @[ > > ext4_writepages+1 > > do_writepages+191 > > __writeback_single_inode+65 > > writeback_sb_inodes+477 > > __writeback_inodes_wb+76 > > wb_writeback+457 > > wb_workfn+680 > > process_one_work+485 > > worker_thread+80 > > kthread+231 > > ret_from_fork+34 > > ]: 2 > > > > Sure, that's fine for ext4, in that particular case, but > > a) not all filesystems have .writepages hooked up. That's why > do_writepages() checks for .writepages(), and falls back to > .writepage(): > > if (mapping->a_ops->writepages) > ret = mapping->a_ops->writepages(mapping, wbc); > else > ret = generic_writepages(mapping, wbc); > > , and > > b) there are also a lot of places and ways to invoke writebacks. There > are periodic writebacks, and there are data integrity (WB_SYNC_ALL) > writebacks, and other places where a page needs to be cleaned--so, a lot > of call sites. Some of which will land on a .writepage() sometimes, even > now. > > For just one example, I see migrate.c's writeout() function directly > calling writepage(): > > rc = mapping->a_ops->writepage(&folio->page, &wbc); Thanks, John. You are right. I think "deprecated" is inaccurate, .writepage is actually no longer used in memory reclaim context, but it is still used for other contexts. Anyway I think what we tried to figure out in the first place is whether it is possible that filesystem writeback have dead lock with the new batch migration or not. I think the conclusion didn't change. > > > thanks, > > -- > John Hubbard > NVIDIA >
