linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Jens Axboe <jens.axboe@oracle.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch,rfc v2] ext3/4: enhance fsync performance when using cfq
Date: Thu, 8 Apr 2010 10:10:04 -0400	[thread overview]
Message-ID: <20100408141004.GC10879@redhat.com> (raw)
In-Reply-To: <x49pr2a9h3n.fsf@segfault.boston.devel.redhat.com>

On Thu, Apr 08, 2010 at 10:03:24AM -0400, Jeff Moyer wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Thu, Apr 08, 2010 at 01:00:45PM +0200, Jens Axboe wrote:
> 
> >> I like the concept, it's definitely useful (and your results amply
> >> demonstrate that). I was thinking if there was a way in through the ioc
> >> itself, rather than bdi -> queue and like you are doing. But I can't
> >> think of a nice way to do it, so this is probably as good as it gets.
> >> 
> >
> > I think, one issue with ioc based approach will be that it will then call
> > yield operation on all the devices in the system where this context has ever
> > done any IO. With bdi based approach this call will remain limited to
> > a smaller set of devices.
> 
> Which actually brings up the question of whether this needs some
> knowledge of whether the journal is on the same device as the file
> system!  In such a case, we need not yield.  I think I'll stick my head
> in the sand for this one.  ;-)

Jeff even if journal is not on same device, what harm yielding could do?
Anyway there is no IO on that queue and we are idling. Only side affect is
that yielding process could lose a bit if after fsync it immediately submits
more IO. Because this process has yielded it slice, it is back in the queue
instead of doing more IO in the current slice immediately.

Vivek

  parent reply	other threads:[~2010-04-08 14:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-07 21:18 [patch,rfc v2] ext3/4: enhance fsync performance when using cfq Jeff Moyer
2010-04-07 21:46 ` Vivek Goyal
2010-04-08 11:04   ` Jens Axboe
2010-04-08 14:05     ` Vivek Goyal
2010-04-08 14:09       ` Jens Axboe
2010-04-08 14:17         ` Vivek Goyal
2010-04-08 14:24         ` Jeff Moyer
2010-04-08 19:23           ` Jens Axboe
2010-04-21 20:42         ` Mike Snitzer
2010-04-21 20:52           ` Jeff Moyer
2010-04-08 11:00 ` Jens Axboe
2010-04-08 13:59   ` Vivek Goyal
2010-04-08 14:03     ` Jens Axboe
2010-04-08 14:03     ` Jeff Moyer
2010-04-08 14:06       ` Jens Axboe
2010-04-08 14:10       ` Vivek Goyal [this message]
2010-04-08 14:25         ` Jeff Moyer
2010-04-08 14:31           ` Vivek Goyal
2010-04-08 19:10   ` Jeff Moyer

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=20100408141004.GC10879@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=jens.axboe@oracle.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).