From: Jeff Moyer <jmoyer@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] cfq: allow dispatching of both sync and async I/O together
Date: Mon, 21 Jun 2010 16:05:34 -0400 [thread overview]
Message-ID: <x49eig06tip.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <4C1FC4B4.3060700@kernel.dk> (Jens Axboe's message of "Mon, 21 Jun 2010 21:59:48 +0200")
Jens Axboe <axboe@kernel.dk> writes:
> On 21/06/10 21.49, Jeff Moyer wrote:
>> Hi,
>>
>> In testing a workload that has a single fsync-ing process and another
>> process that does a sequential buffered read, I was unable to tune CFQ
>> to reach the throughput of deadline. This patch, along with the previous
>> one, brought CFQ in line with deadline when setting slice_idle to 0.
>>
>> I'm not sure what the original reason for not allowing sync and async
>> I/O to be dispatched together was. If there is a workload I should be
>> testing that shows the inherent problems of this, please point me at it
>> and I will resume testing. Until and unless that workload is identified,
>> please consider applying this patch.
>
> The problematic case is/was a normal SATA drive with a buffered
> writer and an occasional reader. I'll have to double check my
> mail tomorrow, but iirc the issue was that the occasional reader
> would suffer great latencies since service times for that single
> IO would be delayed at the drive side. It could perhaps just be
> a bug in how we handle the slice idling on the read side when the
> IO gets delayed initially.
>
> So if my memory is correct, google for the fsync madness and
> interactiveness thread that we had some months ago and which
> caused a lot of tweaking. The commit adding this is
> 5ad531db6e0f3c3c985666e83d3c1c4d53acccf9 and was added back
> in July last year. So it was around that time that the mails went
> around.
OK. Thanks a ton for the pointers! I really appreciate it!
-Jeff
next prev parent reply other threads:[~2010-06-21 20:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-21 19:49 [PATCH 0/2] cfq: fixes to bring cfq in line with deadline performance for mid- to high-end storage Jeff Moyer
2010-06-21 19:49 ` [PATCH 1/2] cfq: always return false from should_idle if slice_idle is set to zero Jeff Moyer
2010-06-21 20:00 ` Jens Axboe
2010-06-28 18:41 ` Jeff Moyer
2010-06-28 18:50 ` Jens Axboe
2010-06-28 18:54 ` Jeff Moyer
2010-06-21 23:05 ` Vivek Goyal
2010-06-21 19:49 ` [PATCH 2/2] cfq: allow dispatching of both sync and async I/O together Jeff Moyer
2010-06-21 19:59 ` Jens Axboe
2010-06-21 20:05 ` Jeff Moyer [this message]
2010-06-21 23:22 ` Vivek Goyal
2010-06-22 4:07 ` Vivek Goyal
2010-06-22 12:45 ` Jeff Moyer
2010-06-22 13:18 ` Vivek Goyal
2010-06-22 13:21 ` Jens Axboe
2010-06-22 14:24 ` Vivek Goyal
2010-06-22 14:27 ` Jeff Moyer
2010-06-28 18:40 ` Jeff Moyer
2010-06-28 18:48 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x49eig06tip.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).