On Tue, Sep 27, 2022 at 8:25 PM Yang Shi <shy828301@xxxxxxxxx> wrote: > > 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. Hmm.. it is definitely used currently, but it seems like the plan is to deprecate ->writepage finally IIUC. See https://lore.kernel.org/linux-mm/YvQYjpDHH5KckCrw@xxxxxxxxxxxxxxxxxxxx/ > > 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 > >
