On Mon, Jan 24, 2022 at 08:55:38AM +0100, Gionatan Danti wrote: > Il 2022-01-23 23:52 Dave Chinner ha scritto: > > 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. > > Hi Dave, > ah, so it forces all threads under the same time slice? I thought it was > thread aware... No, the opposite. e.g. thread A does IO and then runs fsync(), which needs to force the log, that triggers CIL push work which runs in a different thread B. Thread A blocks waiting for the CIL push, thread B runs immediately. Thread B then issues log IO, but the IO from thread B is queued by CFQ because thread A's timeslice hasn't expired. Hence log force is delayed until thread A's timeslice expires, even though it is being done on behalf of thread A and thread A is blocked until the IO from Thread B is scheduled and completed. > Is it the same even for BFQ? No idea - I use noop for everything these days because IO schedulers often cause more problems than they solve on SSDs, sparse virtual machine images, thinly provisioned storage, etc.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
