linux-kernel - Re: [PATCH 6/6] cfq: Increase default value of target

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <x49simr4ntz.fsf@segfault.boston.devel.redhat.com>
Date:	Thu, 26 Jun 2014 12:50:32 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Mel Gorman <mgorman@...e.de>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux-MM <linux-mm@...ck.org>,
	Linux-FSDevel <linux-fsdevel@...r.kernel.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Jens Axboe <axboe@...nel.dk>,
	Dave Chinner <david@...morbit.com>
Subject: Re: [PATCH 6/6] cfq: Increase default value of target_latency

Mel Gorman <mgorman@...e.de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/