linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: axboe@kernel.dk, lucho@ionkov.net, jack@suse.cz,
	ericvh@gmail.com, viro@zeniv.linux.org.uk, rminnich@sandia.gov,
	tytso@mit.edu, martin.petersen@oracle.com, neilb@suse.de,
	david@fromorbit.com, Zheng Liu <gnehzuil.liu@gmail.com>,
	linux-kernel@vger.kernel.org, hch@infradead.org,
	linux-fsdevel@vger.kernel.org, adilger.kernel@dilger.ca,
	bharrosh@panasas.com, jlayton@samba.org,
	v9fs-developer@lists.sourceforge.net, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 4/4] block: Optionally snapshot page contents to provide stable pages during write
Date: Thu, 13 Dec 2012 18:10:49 -0800	[thread overview]
Message-ID: <20121214021048.GF9453@blackbox.djwong.org> (raw)
In-Reply-To: <50CA8556.7030905@mit.edu>

On Thu, Dec 13, 2012 at 05:48:06PM -0800, Andy Lutomirski wrote:
> On 12/13/2012 12:08 AM, Darrick J. Wong wrote:
> > Several complaints have been received regarding long file write latencies when
> > memory pages must be held stable during writeback.  Since it might not be
> > acceptable to stall programs for the entire duration of a page write (which may
> > take many milliseconds even on good hardware), enable a second strategy wherein
> > pages are snapshotted as part of submit_bio; the snapshot can be held stable
> > while writes continue.
> > 
> > This provides a band-aid to provide stable page writes on jbd without needing
> > to backport the fixed locking scheme in jbd2.  A mount option is added to ext4
> > to allow administrators to enable it there.
> 
> I'm a bit confused as to what it has to do with ext3.  Wouldn't this be
> useful as a mount option everywhere, though?

ext3 requires snapshots; the rest are ok with either strategy.

*If* snapshotting is generally liked, then yes I'll go redo it as a vfs mount
option.

> If this becomes widely used, would it be better to snapshot on
> wait_for_stable_page instead of on io submission?

That really depends on how long you can afford to wait and how much free
memory you have. :)  It's all a big tradeoff between write latency and
consumption of memory pages and bandwidth, and one that I doubt I'm qualified
to make for everyone.

> FWIW, I'm about to pound pretty hard on this whole patchset on a box
> that doesn't need stable pages.  I'll let you know how it goes.

Yay!

--D

  reply	other threads:[~2012-12-14  2:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-13  8:07 [PATCH v2.3 0/3] mm/fs: Implement faster stable page writes on filesystems Darrick J. Wong
2012-12-13  8:07 ` [PATCH 1/4] bdi: Allow block devices to say that they require stable page writes Darrick J. Wong
2012-12-17  9:04   ` Jan Kara
2012-12-13  8:07 ` [PATCH 2/4] mm: Only enforce stable page writes if the backing device requires it Darrick J. Wong
2012-12-17  9:16   ` Jan Kara
2012-12-13  8:08 ` [PATCH 3/4] 9pfs: Fix filesystem to wait for stable page writeback Darrick J. Wong
2012-12-17 10:11   ` Jan Kara
2012-12-13  8:08 ` [PATCH 4/4] block: Optionally snapshot page contents to provide stable pages during write Darrick J. Wong
2012-12-14  1:48   ` Andy Lutomirski
2012-12-14  2:10     ` Darrick J. Wong [this message]
2012-12-14  3:33       ` Dave Chinner
2012-12-14 19:43         ` Darrick J. Wong
2012-12-15  1:12       ` Andy Lutomirski
2012-12-15  2:01         ` Darrick J. Wong
2012-12-15  2:06           ` Andy Lutomirski
2012-12-17 22:54             ` Darrick J. Wong
2012-12-16 16:13   ` Zheng Liu
2012-12-17 22:56     ` Darrick J. Wong
2012-12-17 10:23   ` Jan Kara
2012-12-17 23:20     ` Darrick J. Wong
2012-12-27 19:14   ` OGAWA Hirofumi
2012-12-27 21:40     ` Darrick J. Wong
2012-12-27 21:48       ` OGAWA Hirofumi
2013-01-07 20:44         ` Darrick J. Wong
2013-01-08  9:44           ` OGAWA Hirofumi

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=20121214021048.GF9453@blackbox.djwong.org \
    --to=darrick.wong@oracle.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=axboe@kernel.dk \
    --cc=bharrosh@panasas.com \
    --cc=david@fromorbit.com \
    --cc=ericvh@gmail.com \
    --cc=gnehzuil.liu@gmail.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=jlayton@samba.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=luto@amacapital.net \
    --cc=martin.petersen@oracle.com \
    --cc=neilb@suse.de \
    --cc=rminnich@sandia.gov \
    --cc=tytso@mit.edu \
    --cc=v9fs-developer@lists.sourceforge.net \
    --cc=viro@zeniv.linux.org.uk \
    /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).