All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: cmm@us.ibm.com, sandeen@redhat.com, linux-ext4@vger.kernel.org
Subject: Re: [PATCH -V2] ext4: Drop mapped buffer_head check during page_mkwrite
Date: Fri, 28 Aug 2009 22:26:56 -0400	[thread overview]
Message-ID: <20090829022656.GK16732@mit.edu> (raw)
In-Reply-To: <1251264196-31382-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>

On Wed, Aug 26, 2009 at 10:53:16AM +0530, Aneesh Kumar K.V wrote:
> Inorder to check whether the buffer_heads are mapped we need
> to hold page lock. Otherwise a reclaim can cleanup the attached
> buffer_heads. Instead of taking page lock and check whether
> buffer_heads are mapped we let the write_begin/write_end callback
> does the equivalent. It does have a performance impact in that we
> are doing more work if we the buffer_heads are already mapped.

So I started looking at all of the work that we need to do in
write_begin/write_end; did you check both write paths depending on
whether we are using delayed allocation or not?  It would seem to me
that it might be better to use lock_page() and unlock_page() around
the check, since in many work loads the buffer heads will already be
mapped often, and it appears to me that write_begin() will end up
locking the page anyway.

Am I missing something?

						- Ted

  reply	other threads:[~2009-08-29  2:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-26  5:23 [PATCH -V2] ext4: Drop mapped buffer_head check during page_mkwrite Aneesh Kumar K.V
2009-08-29  2:26 ` Theodore Tso [this message]
2009-08-31  6:30   ` Aneesh Kumar K.V
2009-08-31 12:24     ` Theodore Tso
2009-08-31 12:33       ` Aneesh Kumar K.V
2009-08-31 12:50         ` Theodore Tso
2009-08-31 17:06           ` Aneesh Kumar K.V
2009-09-06  3:49             ` Theodore Tso
2009-09-07 12:22               ` Aneesh Kumar K.V
2009-09-07  9:44     ` [PATCH -v3] ext4: Take page lock before looking at attached buffer_heads flags Aneesh Kumar K.V
2009-09-10  3:25       ` Theodore Tso

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=20090829022656.GK16732@mit.edu \
    --to=tytso@mit.edu \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cmm@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@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.