From: Vivek Goyal <vgoyal@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: Fengguang Wu <fengguang.wu@intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
"Myklebust, Trond" <Trond.Myklebust@netapp.com>,
linux-fsdevel@vger.kernel.org,
Linux Memory Management List <linux-mm@kvack.org>,
Jens Axboe <axboe@kernel.dk>
Subject: Re: write-behind on streaming writes
Date: Thu, 7 Jun 2012 15:06:13 -0400 [thread overview]
Message-ID: <20120607190613.GC18538@redhat.com> (raw)
In-Reply-To: <20120607094504.GB25074@quack.suse.cz>
On Thu, Jun 07, 2012 at 11:45:04AM +0200, Jan Kara wrote:
[..]
> > Instead of above, I modified sync_file_range() to call
> > __filemap_fdatawrite_range(WB_SYNC_NONE) and I do see now ASYNC writes
> > showing up at elevator.
> >
> > With 4 processes doing sync_file_range() now, firefox start time test
> > clocks around 18-19 seconds which is better than 30-35 seconds of 4
> > processes doing buffered writes. And system looks pretty good from
> > interactivity point of view.
> So do you have any idea why is that? Do we drive shallower queues? Also
> how does speed of the writers compare to the speed with normal buffered
> writes + fsync (you'd need fsync for sync_file_range writers as well to
> make comparison fair)?
Ok, I did more tests and few odd things I noticed.
- Results are varying a lot. Sometimes with write+flush workload also firefox
launched fast. So now it is hard to conclude things.
- For some reason I had nr_requests as 16K on my root drive. I have no
idea who is setting it. Once I set it to 128, then firefox with
write+flush workload performs much better and launch time are similar
to sync_file_range.
- I tried to open new windows in firefox and browse web, load new
websites. I would say sync_file_range() feels little better but
I don't have any logical explanation and can't conclude anything yet
by looking at traces. I am continuing to stare though.
So in summary, at this point of time I really can't conclude that
using sync_file_range() with ASYNC request is providing better latencies
in my setup.
I will keept at it though and if I notice something new, will write back.
Thanks
Vivek
next prev parent reply other threads:[~2012-06-07 19:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-28 11:41 [GIT PULL] writeback changes for 3.5-rc1 Fengguang Wu
2012-05-28 17:09 ` Linus Torvalds
2012-05-29 15:57 ` write-behind on streaming writes Fengguang Wu
2012-05-29 17:35 ` Linus Torvalds
2012-05-30 3:21 ` Fengguang Wu
2012-06-05 1:01 ` Dave Chinner
2012-06-05 17:18 ` Vivek Goyal
2012-06-05 17:23 ` Vivek Goyal
2012-06-05 17:41 ` Vivek Goyal
2012-06-05 18:48 ` Vivek Goyal
2012-06-05 20:10 ` Vivek Goyal
2012-06-06 2:57 ` Vivek Goyal
2012-06-06 3:14 ` Linus Torvalds
2012-06-06 12:14 ` Vivek Goyal
2012-06-06 14:00 ` Fengguang Wu
2012-06-06 17:04 ` Vivek Goyal
2012-06-07 9:45 ` Jan Kara
2012-06-07 19:06 ` Vivek Goyal [this message]
2012-06-06 16:15 ` Vivek Goyal
2012-06-06 14:08 ` Fengguang Wu
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=20120607190613.GC18538@redhat.com \
--to=vgoyal@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=axboe@kernel.dk \
--cc=fengguang.wu@intel.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@linux-foundation.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).