From: Vivek Goyal <vgoyal@redhat.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Corrado Zoccolo <czoccolo@gmail.com>,
axboe@kernel.dk, Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] cfq-iosched: fixing RQ_NOIDLE handling.
Date: Mon, 19 Jul 2010 16:31:09 -0400 [thread overview]
Message-ID: <20100719203109.GE32503@redhat.com> (raw)
In-Reply-To: <x4939vfv4i0.fsf@segfault.boston.devel.redhat.com>
On Mon, Jul 19, 2010 at 12:08:23PM -0400, Jeff Moyer wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
>
> > On Tue, Jul 13, 2010 at 04:30:23PM -0400, Jeff Moyer wrote:
> >> Vivek Goyal <vgoyal@redhat.com> writes:
>
> > I don't mind looking at traces. Do let me know where can I access those.
>
> Forwarded privately.
>
> >> Now, to answer your question, the jbd2 thread runs and issues a barrier,
> >> which causes a forced dispatch of requests. After that a new queue is
> >> selected, and since the fs_mark thread is blocked on the journal commit,
> >> it's always the fio process that gets to run.
> >
> > Ok, that explains it. So somehow after the barrier, fio always wins
> > as issues next read request before the fs_mark is able to issue the
> > next set of writes.
> >
> >>
> >> This, of course, raises the question of why the blk_yield patches didn't
> >> run into the same problem. Looking back at some saved traces, I don't
> >> see WBS (write barrier sync) requests, so I wonder if barriers weren't
> >> supported by my last storage system.
> >
> > I think that blk_yield patches will also run into the same issue if
> > barriers are enabled.
>
> Agreed.
>
> Here are the results again with barriers disabled for Corrado's patch:
>
> fs_mark: 348.2 files/sec
> fio: 53324.6 KB/s
>
> Remember that deadline was seeing 450 files/sec and 78 MB/s. So, in
> this case, the buffered reader appears to be starved. Looking into this
> further, I found that the journal thread is running with I/O priority 0,
> while the fio and fs_mark processes are running at the default (4).
> Because the jbd thread has a higher I/O priority, its requests are
> always closer to the front of the sort list, and thus the sync-noidle
> workload is chosen more often than the sync workload. This essentially
> results in an elevated I/O priority for the fs_mark process as well.
> While troubling, that problem is not directly related to the problem
> we're looking at.
>
> So, I'm still in favor of Corrado's approach. Are there any remaining
> dissenting opinions on this?
Nope. I am fine with moving all WRITE_SYNC with RQ_NOIDLE to sync-noidle
tree and also marking jbd writes as WRITE_SYNC. By bringing dependent
threads on single service tree, we don't have to worry about slice
yielding.
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Thanks
Vivek
next prev parent reply other threads:[~2010-07-19 20:31 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-07 15:22 [PATCH 0/2] cfq-iosched: fixing RQ_NOIDLE handling Corrado Zoccolo
2010-07-07 15:56 ` Corrado Zoccolo
2010-07-07 17:03 ` Jeff Moyer
2010-07-07 17:39 ` Corrado Zoccolo
2010-07-07 20:06 ` Jeff Moyer
2010-07-08 14:38 ` Corrado Zoccolo
2010-07-09 10:33 ` Corrado Zoccolo
2010-07-09 13:23 ` Vivek Goyal
2010-07-09 14:07 ` Jeff Moyer
2010-07-09 19:45 ` Corrado Zoccolo
2010-07-09 20:48 ` Jeff Moyer
2010-07-13 19:38 ` Jeff Moyer
2010-07-13 19:56 ` Vivek Goyal
2010-07-13 20:30 ` Jeff Moyer
2010-07-13 20:42 ` Vivek Goyal
2010-07-19 16:08 ` Jeff Moyer
2010-07-19 20:31 ` Vivek Goyal [this message]
2010-07-20 14:02 ` Jeff Moyer
2010-07-20 14:11 ` Christoph Hellwig
2010-07-20 14:26 ` Vivek Goyal
2010-07-20 19:10 ` Corrado Zoccolo
2010-07-20 19:32 ` Vivek Goyal
2010-07-13 21:00 ` Jeff Moyer
2010-07-07 17:50 ` Vivek Goyal
2010-07-08 14:35 ` Vivek Goyal
2010-07-08 14:38 ` Jeff Moyer
2010-07-08 14:45 ` Corrado Zoccolo
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=20100719203109.GE32503@redhat.com \
--to=vgoyal@redhat.com \
--cc=axboe@kernel.dk \
--cc=czoccolo@gmail.com \
--cc=jmoyer@redhat.com \
--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