Mel Gorman <mgorman@xxxxxxx> writes: > On Thu, Jun 26, 2014 at 11:36:50AM -0400, Jeff Moyer wrote: >> Right, and I guess I hadn't considered that case as I thought folks used >> more than one spinning disk for such workloads. >> > > They probably are but by and large my IO testing is based on simple > storage. The reasoning is that if we get the simple case wrong then we > probably are getting the complex case wrong too or at least not performing > as well as we should. I also don't use SSD on my own machines for the > same reason. A single disk is actually the hard case in this instance, but I understand what you're saying. ;-) >> My main reservation about this change is that you've only provided >> numbers for one benchmark. > > The other obvious one to run would be pgbench workloads but it's a rathole of > arguing whether the configuration is valid and whether it's inappropriate > to test on simple storage. The tiobench tests alone take a long time to > complete -- 1.5 hours on a simple machine, 7 hours on a low-end NUMA machine. And we should probably run our standard set of I/O exercisers at the very least. But, like I said, it seems like wasted effort. >> 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) >> > > Ok, you've convinced me and I'll drop this patch. For anyone based on > kernels from around this time they can tune CFQ or buy a better disk. > Hopefully they will find this via Google. Funny, I wasn't weighing in against your patch. I was merely indicating that I personally wasn't going to invest the time to validate it. But, if you're ok with dropping it, that's obviously fine with me. 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>