Re: [PATCH 6/6] cfq: Increase default value of target_latency

[Jeff Moyer]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/