From: Jeff Moyer <jmoyer@redhat.com>
To: tytso@mit.edu
Cc: Vivek Goyal <vgoyal@redhat.com>, Jan Kara <jack@suse.cz>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
jens.axboe@oracle.com, esandeen@redhat.com
Subject: Re: [patch/rft] jbd2: tag journal writes as metadata I/O
Date: Tue, 06 Apr 2010 15:04:53 -0400 [thread overview]
Message-ID: <x491vesqu5m.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <20100406184505.GL23670@thunk.org> (tytso@mit.edu's message of "Tue, 6 Apr 2010 14:45:05 -0400")
tytso@mit.edu writes:
>> CFQ currently seems to be preempting any thread doing IO if a request has
>> been marked as metadata. I think this is going to be bad for any other IO
>> going on.
>>
>> I wrote a small fio script which is doing buffered writes with bs=32K and I
>> am doing fsync on file after every 20 IOs (fsync=20). I am assuming that this
>> something close to writting a small file and then doing fsync on that.
>>
>> With that fio script running I launched firefox and measured the
>> time it takes..... it looks like that firefox launching times have
>> seems to just almost doubled.
>
> Vivek, thanks for pointing this out. Sounds like we need to think
> carefully about whether the potential unfairness that this patch might
> impose on other workloads sharing the file system dominates the
> improvements that Jeff found when there's only a single workload
> running on the file system.
>
> I'm tentatively leaning towards pulling this patch so we can do more
> testing / benchmarking. Jeff, any thoughts or comments?
Yeah, pull it. I just talked this over with Vivek, and looking back at
the blktrace data I think I have another idea that might work and be
less invasive.
Basically, the iozone process is, umm, special. It does the following
at startup (from memory, so I might've missed a step):
open(fd);
truncate(fd,0);
close(fd)
open(fd);
fsync(fd);
*then* it does I/O.
So, we get a sync cfqq for the iozone process that ends up doing the
metadata lookups. Then it does the truncate and of course blocks. At
this point, we are waiting for jbd2 to run to sync out its transaction.
However, we're idling on the iozone cfqq, so it doesn't get a chance to
run for 8ms.
If we instead just pass a hint down to the I/O scheduler on fsync,
similar to the schedule() call for the cpu scheduler, then I think we
can give up our time slice and allow the jbd2 process to run.
I'll report back with my findings. Vivek, thanks a ton for the careful
(as always) review.
Cheers,
Jeff
next prev parent reply other threads:[~2010-04-06 19:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-01 19:04 [patch/rft] jbd2: tag journal writes as metadata I/O Jeff Moyer
2010-04-01 19:48 ` Jan Kara
2010-04-05 15:24 ` Jeff Moyer
2010-04-05 17:46 ` tytso
2010-04-06 15:20 ` Jan Kara
2010-04-06 18:25 ` Vivek Goyal
2010-04-06 18:45 ` tytso
2010-04-06 19:04 ` Jeff Moyer [this message]
2010-04-02 7:00 ` Jens Axboe
2010-04-05 17:52 ` tytso
2010-04-05 18:36 ` Jeff Moyer
2010-04-05 19:48 ` tytso
2010-04-05 20:34 ` Jeff Moyer
2010-04-05 20:41 ` Jeff Moyer
2010-04-05 21:01 ` tytso
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=x491vesqu5m.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=esandeen@redhat.com \
--cc=jack@suse.cz \
--cc=jens.axboe@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=vgoyal@redhat.com \
/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).