On Mon, Jun 29, 2020 at 8:24 PM Tom Seewald <tseewald@xxxxxxxxx> wrote: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1851783 > > > > The main argument is that for typical and varied workloads in Fedora, > > mostly on consumer hardware, we should use mq-deadline scheduler > > rather than either none or bfq. > > > > It may be true most folks with NVMe won't see anything bad with none, > > but those who have heavier IO workloads are likely to be better off > > with mq-deadline. > > > > Further details are in the bug, but let's discuss it on list. Thanks!g > > I'm a little confused by this proposal because last year the author of bfq, Paolo Valente, worked with the Fedora community to switch to bfq by default on non-NVMe drives [1]. Now another kernel developer is telling us that bfq has performance problems that ostensibly aren't being fixed. So my immediate question is: have these problems been reported to Paolo and what has his response been? Thanks for the background, I'd forgotten about that. I am seeing only one Fedora bug report upstream (maybe it's a two in one) and they've been responsive, but it was an oops not a performance complaint. https://bugzilla.kernel.org/show_bug.cgi?id=205447 > From what I can tell bfq was chosen because it improved the responsiveness of the desktop, and so I'm curious where it's falling short. Are there performance issues with workloads that Fedora users are running, or have these latency spikes primarily been seen with Facebook's server workloads? The latter but considering they're a broad variety of workloads I think it's misleading to call them server workloads as if that's one particular type of thing, or not applicable to a desktop under IO pressure. Why? (a) they're using consumer storage devices (b) these are real workloads rather than simulations (c) even by upstream's own descriptions of the various IO schedulers only mq-deadline is intended to be generic. (d) it's really hard to prove anything in this area without a lot of data. But fair enough, I'll see about collecting some data before asking to change the IO scheduler yet again. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
