linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Dave Chinner <david@fromorbit.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: semi-stable page writes
Date: Wed, 31 Oct 2012 12:45:45 +0100	[thread overview]
Message-ID: <20121031114545.GB18424@quack.suse.cz> (raw)
In-Reply-To: <20121030233021.GG29378@dastard>

On Wed 31-10-12 10:30:21, Dave Chinner wrote:
> On Mon, Oct 29, 2012 at 09:00:27PM -0400, Theodore Ts'o wrote:
> > On Tue, Oct 30, 2012 at 09:01:22AM +1100, Dave Chinner wrote:
> > > On Fri, Oct 26, 2012 at 03:19:09AM -0700, Darrick J. Wong wrote:
> > > > Hi everyone,
> > > > 
> > > > Are people still annoyed about writes taking unexpectedly long amounts of tme
> > > > due to the stable page write patchset?  I'm guessing yes...
> > > 
> > > I haven't heard anyone except th elunatic fringe complain
> > > recently...
> > 
> > We are currently carrying a patch in the Google kernel which
> > unconditionally disables stable page writes specifically because it
> > introduced significant latencies that were unacceptable for some of
> > our (internal) customers of said production kernel.
> > 
> > I'll leave it to others to decide whether the Google production kernel
> > is part of the lunatic fringe or not.  :-)
> 
> Google is, and has the resources to maintain a lunatic fringe kernel
> ;)
> 
> Besides, we've discussed google's problem before, and it came down
> to bad application design (i.e. no buffering to protect against
> variable filesystem/storage latency) and not stable pages being the
> source of the problem. Turning off stable pages was a hack to work
> around a badly designed application stack....
  Well, so far I heard like 4 or 5 complaints about performance that were
tracked down to stable pages. Likely the most convincing was a case of an
application mmaping 1 GB file and randomly changing bits here and there.
Throughput of that application dropped to about a third with stable pages
(which surprised me at the first sight but after doing the math it's
obvious).

  As much as I agree that the problems can be solved in the applications
(if you have the liberty to modify them...), reported problems seem to be
common enough so that we try to do better than we do now.

> > IMO, it would be better to have the system automatically do the right
> > thing, though.  If there is no need for stable page writes, why pay
> > the performance penalty for it?
> 
> Yes, and the right thing to do is to put correctness before performance.
> Stable pages are needed for correctness in a lot of cases, so that shoul
> dbe the default. If the user has performance problems, then they can turn
> it off. At no time should the default require tuning to get correct
> behaviour. case in point: filesystems default to "barriers = on".
  I agree here. But still that does not rule out the possibility of getting
it right in the kernel without having to enable stable pages in all cases.
I.e., if btrfs needs stable pages, let it set the flag that it needs them.
Same for DIF/DIX, RAID5 or whatever else...

								Honza

  reply	other threads:[~2012-10-31 11:45 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-26 10:19 semi-stable page writes Darrick J. Wong
2012-10-27  1:35 ` [RFC PATCH 1/2] bdi: Create a flag to indicate that a backing device needs stable " Darrick J. Wong
2012-10-29 18:13   ` Jan Kara
2012-10-29 18:30     ` Jan Kara
2012-10-29 23:48       ` NeilBrown
2012-10-30  0:10         ` Jan Kara
2012-10-30  0:34           ` NeilBrown
2012-10-30 13:38             ` Jan Kara
2012-10-30 21:49               ` NeilBrown
2012-10-30  4:10   ` Martin K. Petersen
2012-10-30  4:48     ` NeilBrown
2012-10-30 12:19       ` Martin K. Petersen
2012-10-30 20:14         ` Darrick J. Wong
2012-10-30 22:14           ` NeilBrown
2012-10-30 23:58             ` Boaz Harrosh
2012-10-31  8:56             ` Darrick J. Wong
2012-10-31 11:56               ` Jan Kara
2012-10-31 19:36                 ` Darrick J. Wong
2012-10-31 23:12                   ` Boaz Harrosh
2012-11-01  5:51                     ` Darrick J. Wong
2012-11-01  6:25                       ` Boaz Harrosh
2012-11-01  8:59                   ` Jan Kara
2012-11-01 17:24                     ` Boaz Harrosh
2012-11-01 22:42                       ` Jan Kara
2012-10-30 22:40   ` Boaz Harrosh
2012-10-27  1:36 ` [RFC PATCH 2/2] mm: Gate stable page writes on the bdi flag Darrick J. Wong
2012-10-29 18:28   ` Jan Kara
2012-10-31  8:58     ` Darrick J. Wong
2012-10-29 22:01 ` semi-stable page writes Dave Chinner
2012-10-30  1:00   ` Theodore Ts'o
2012-10-30 23:30     ` Dave Chinner
2012-10-31 11:45       ` Jan Kara [this message]
2012-10-30 20:40   ` Darrick J. Wong
2012-10-30 23:43     ` Dave Chinner
2012-10-31  9:05       ` Darrick J. Wong

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=20121031114545.GB18424@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@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).