All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.