All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: David Howells <dhowells@redhat.com>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] VM: Fix the gfp_mask in invalidate_complete_page2
Date: Tue, 10 Oct 2006 09:22:57 -0400	[thread overview]
Message-ID: <452B9EB1.4090806@RedHat.com> (raw)
In-Reply-To: <1160483226.5466.34.camel@lade.trondhjem.org>



Trond Myklebust wrote:
> On Tue, 2006-10-10 at 08:18 -0400, Steve Dickson wrote:
>> Trond Myklebust wrote:
>>> No. Invalidatepage does precisely the wrong thing: it invalidates dirty
>>> data instead of committing it to disk. If you need to have the data
>>> invalidated, then you should call truncate_inode_pages().
>> Just curious... would it make sense to call truncate_inode_pages()
>> to purge the the readdir cache? Meaning, in nfs_revalidate_mapping()
>> truncate_inode_pages() would be called for S_ISDIR inodes?
> 
> Why? If, as in the case of an NFS directory, there are no dirty pages
> then the two are supposed to be 100% equivalent.
Well as you know, lately we've had problems with 
invalidate_inode_pages2() failing to invalidate pages (regardless of
their state). So I was thinking truncate_inode_pages() might be
better for directories since there seem to be more a guarantee that
the pages will be gone with truncate_inode_pages() than
invalidate_inode_pages2() (due to the fact there will not be any
dirty pages).

But since you have to call truncate_inode_pages under the
inode->i_mutex, there might be a performance hit...

steved.


  reply	other threads:[~2006-10-10 13:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-06 21:37 [PATCH] VM: Fix the gfp_mask in invalidate_complete_page2 Trond Myklebust
2006-10-06 21:49 ` Steve Dickson
2006-10-06 22:16   ` Trond Myklebust
2006-10-06 22:19     ` Trond Myklebust
2006-10-06 22:40       ` Andrew Morton
2006-10-06 23:09         ` Steve Dickson
2006-10-06 23:20           ` Andrew Morton
2006-10-07  2:33           ` Andrew Morton
2006-10-10  9:43 ` David Howells
2006-10-10 11:42   ` Trond Myklebust
2006-10-10 12:18     ` Steve Dickson
2006-10-10 12:27       ` Trond Myklebust
2006-10-10 13:22         ` Steve Dickson [this message]
2006-10-10 13:32           ` Trond Myklebust
2006-10-10 12:49     ` David Howells
2006-10-10 13:15       ` Trond Myklebust

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=452B9EB1.4090806@RedHat.com \
    --to=steved@redhat.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=akpm@osdl.org \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.