On Sun, Jan 23, 2022 at 10:27:32PM +0100, Gionatan Danti wrote: > Hi list, > I have a question about CFQ scheduler and the old warning one can find on > the faq page: "As of kernel 3.2.12, the default i/o scheduler, CFQ, will > defeat much of the parallelization in XFS". > > Can I ask for more information about the bad interaction between CFQ and > XFS, and especially why it does defeat filesystem parallelization? Is this > warning still valid? What about the newer BFQ? CFQ doesn't understand that IO from different threads/tasks are related and so it cannot account for/control multi-threaded IO workloads. Given that XFS's journal IO is inherently a multi-threaded IO workload, CFQ IO accounting and throttling simply does not work properly with XFS or any other filesystem that decouples IO from the user task context that requires the IO to be done on it's behalf. > Note: I always used deadline or noop with XFS, but I am facing a disk with > random read starvation when NCQ is enabled and a mixed sequential & random > load happens. So far I saw that the only scheduler (somewhat) immune to the > issue is CFQ, probably because it does not mix IO from multiple processes > (it issue IO from one process at time, if I understand it correctly). And, as per above, that's exactly why it doesn't work well with XFS... Read starvation during sequential writes sounds more like a problem with the block layer writeback throttle or something you need to use an IO controller (blk-cgroups) to address, not try to fix with a IO scheduler... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
