All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: sct@redhat.com, jack@suse.cz, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, Ext2-devel@lists.sourceforge.net
Subject: Re: [RFC PATCH] ext3 writepage() journal avoidance
Date: Thu, 9 Mar 2006 15:22:54 -0800	[thread overview]
Message-ID: <20060309152254.743f4b52.akpm@osdl.org> (raw)
In-Reply-To: <1141929562.21442.4.camel@dyn9047017100.beaverton.ibm.com>

Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> I am trying to speed up ext3 writepage() by avoiding
> journaling in non-block allocation cases. Does this
> look reasonable ? So far, my testing is fine. What am 
> I missing here ?

Nothing.  ext3's writepage(), prepare_write() and commit_write() do often
needlessy open and close transactions when we're doing overwrites.  It's
something I've meant to look at for a few years, on and off.

I'd expect that prepare_write() and commit_write() are more important than
writepage().

It might be better to test PageMappedToDisk() rather than walking the
buffers.  It's certainly faster and it makes optimisation of
prepare_write() and commit_write() easier to handle.

I'm not sure that PageMappedToDisk() gets set in all the right places
though - it's mainly for the `nobh' handling and block_prepare_write()
would need to be taught to set it.  I guess that'd be a net win, even if
only ext3 uses it..

Then again, we might be able to speed up block_prepare_write() if
PageMappedToDisk(page).

If we go this way we need to be very very careful to keep PG_mappedtodisk
coherent with the state of the buffers.  Tricky.  We need to think about
whether block_truncate_page() should be clearing PG_mappedtoisk if we did a
partial truncate.

Don't forget that ext3 supports journalled-mode files on ordered- or
writeback-mounted filesystems, via `chattr +j'.  Please be sure to test the
various combinations which that allows when playing with the write paths -
it can trip things up.

Also be sure to test nobh-mode.

  reply	other threads:[~2006-03-09 23:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-09 18:39 [RFC PATCH] ext3 writepage() journal avoidance Badari Pulavarty
2006-03-09 23:22 ` Andrew Morton [this message]
2006-03-10  0:45   ` Badari Pulavarty
2006-03-10  0:45     ` Badari Pulavarty
2006-03-10  1:16     ` Andrew Morton
2006-03-10  7:59   ` Arjan van de Ven
2006-03-10  8:23     ` Andrew Morton
2006-03-10  8:23       ` Andrew Morton
2006-03-10  8:43       ` Arjan van de Ven
2006-03-10  8:53         ` Andrew Morton
2006-03-10 14:58           ` Badari Pulavarty
2006-03-10 16:19         ` Dave Jones
2006-03-10 16:19           ` Dave Jones
2006-03-10 16:40           ` Badari Pulavarty
2006-03-10 16:51             ` Dave Jones
2006-03-10 17:00               ` Badari Pulavarty
2006-03-10 16:46           ` Badari Pulavarty
2006-03-10 13:43       ` Dave Kleikamp

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=20060309152254.743f4b52.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=Ext2-devel@lists.sourceforge.net \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.com \
    --cc=sct@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.