Mel Gorman <mgorman@xxxxxxx> writes: > The existing CFQ default target_latency results in very poor performance > for larger numbers of threads doing sequential reads. While this can be > easily described as a tuning problem for users, it is one that is tricky > to detect. This patch updates the default to benefit smaller machines. > Dave Chinner points out that it is dangerous to assume that people know > how to tune their IO scheduler. Jeff Moyer asked what workloads even > care about threaded readers but it's reasonable to assume file, > media, database and multi-user servers all experience large sequential > readers from multiple sources at the same time. Right, and I guess I hadn't considered that case as I thought folks used more than one spinning disk for such workloads. My main reservation about this change is that you've only provided numbers for one benchmark. To bump the default target_latency, ideally we'd know how it affects other workloads. However, I'm having a hard time justifying putting any time into this for a couple of reasons: 1) blk-mq pretty much does away with the i/o scheduler, and that is the future 2) there is work in progress to convert cfq into bfq, and that will essentially make any effort put into this irrelevant (so it might be interesting to test your workload with bfq) Cheers, Jeff -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>