linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Nick Piggin <npiggin@suse.de>
Cc: torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
	akpm@linux-foundation.org
Subject: Re: [PATCH 6/6] writeback: limit write_cache_pages integrity scanning to current EOF
Date: Tue, 8 Jun 2010 16:59:22 +1000	[thread overview]
Message-ID: <20100608065922.GA7869@dastard> (raw)
In-Reply-To: <20100608053831.GR26335@laptop>

On Tue, Jun 08, 2010 at 03:38:31PM +1000, Nick Piggin wrote:
> On Tue, Jun 08, 2010 at 10:38:07AM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > sync can currently take a really long time if a concurrent writer is
> > extending a file. The problem is that the dirty pages on the address
> > space grow in the same direction as write_cache_pages scans, so if
> > the writer keeps ahead of writeback, the writeback will not
> > terminate until the writer stops adding dirty pages.
> > 
> > For a data integrity sync, we only need to write the pages dirty at
> > the time we start the writeback, so we can stop scanning once we get
> > to the page that was at the end of the file at the time the scan
> > started.
> > 
> > This will prevent operations like copying a large file preventing
> > sync from completing as it will not write back pages that were
> > dirtied after the sync was started. This does not impact the
> > existing integrity guarantees, as any dirty page (old or new)
> > within the EOF range at the start of the scan will still be
> > captured.
> > 
> > This patch will not prevent sync from blocking on large writes into
> > holes.
> 
> The writes don't have to be into holes to cause this starvation
> problem, do they?

No, they don't.

> > That requires more complex intervention while this patch only
> > addresses the common append-case of this sync holdoff.
> 
> Jan's tagging patch looks pretty good to me and isn't so complex.
> I think we should just take that.

I don't care which one we take as long as it is actually tested by
more than the submitter and we get everything in for 2.6.35...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2010-06-08  6:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-08  0:38 [PATCH 0/6] writeback: tracing and fixes V4 Dave Chinner
2010-06-08  0:38 ` [PATCH 1/6] writeback: initial tracing support Dave Chinner
2010-06-08  0:38 ` [PATCH 2/6] writeback: Add tracing to balance_dirty_pages Dave Chinner
2010-06-08  0:38 ` [PATCH 3/6] writeback: Add tracing to write_cache_pages Dave Chinner
2010-06-08  0:38 ` [PATCH 4/6] writeback: pay attention to wbc->nr_to_write in write_cache_pages Dave Chinner
2010-06-08  5:43   ` Nick Piggin
2010-06-08  0:38 ` [PATCH 5/6] xfs: remove nr_to_write writeback windup Dave Chinner
2010-06-08  0:38 ` [PATCH 6/6] writeback: limit write_cache_pages integrity scanning to current EOF Dave Chinner
2010-06-08  5:38   ` Nick Piggin
2010-06-08  6:59     ` Dave Chinner [this message]
2010-06-08  5:44 ` [PATCH 0/6] writeback: tracing and fixes V4 Nick Piggin
2010-06-08 17:41 ` Linus Torvalds
2010-06-08 17:50   ` Andrew Morton
2010-06-08 22:46   ` Dave Chinner
  -- strict thread matches above, loose matches on Subject: below --
2010-06-03 23:55 [PATCH 0/6] writeback: tracing and fixes V3 Dave Chinner
2010-06-03 23:55 ` [PATCH 6/6] writeback: limit write_cache_pages integrity scanning to current EOF Dave Chinner
2010-06-04  7:52   ` Christoph Hellwig
2010-06-04  7:56     ` Nick Piggin
2010-05-25 10:54 [PATCH 0/6] writeback: tracing and fixes Dave Chinner
2010-05-25 10:54 ` [PATCH 6/6] writeback: limit write_cache_pages integrity scanning to current EOF Dave Chinner
2010-05-27 21:33   ` Andrew Morton
2010-05-28  1:23     ` Dave Chinner
2010-05-28  5:06     ` Nick Piggin
2010-06-01 15:54     ` Jan Kara

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=20100608065922.GA7869@dastard \
    --to=david@fromorbit.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=torvalds@linux-foundation.org \
    --cc=xfs@oss.sgi.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).