From: Andrew Morton <akpm@osdl.org>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Zach Brown <zach.brown@oracle.com>, linux-kernel@vger.kernel.org
Subject: Re: [patch] call truncate_inode_pages in the DIO fallback to buffered I/O path
Date: Wed, 4 Oct 2006 16:55:04 -0700 [thread overview]
Message-ID: <20061004165504.c1dd3dd3.akpm@osdl.org> (raw)
In-Reply-To: <x49ejtn7qfy.fsf@segfault.boston.devel.redhat.com>
On Wed, 04 Oct 2006 16:53:53 -0400
Jeff Moyer <jmoyer@redhat.com> wrote:
> The man page for open states:
>
> O_DIRECT
> Try to minimize cache effects of the I/O to and from this file.
>
> I think that invalidating the page cache pages we use when falling back to
> buffered I/O stays true to the above description.
What the manpage forgot to mention is "direct-io is synchronous".
Except it isn't, when we fall back to buffered-IO. So yup, I think we
could justify this (sort of) change on those grounds alone: preserving the
synchronous semantics.
I'd propose that we do this via
generic_file_buffered_write(...);
do_sync_file_range(..., SYNC_FILE_RANGE_WAIT_BEFORE|
SYNC_FILE_RANGE_WRITE|
SYNC_FILE_RANGE_WAIT_AFTER)
invalidate_mapping_pages(...);
There is a slight inefficiency here: generic_file_direct_IO() does
invalidate_inode_pages2_range(), then we go and instantiate some pagecache,
then we strip it away again with invalidate_mapping_pages(). That first
invalidate_inode_pages2_range() was somewhat of a waste of cycles.
But we expect that the next call to generic_file_direct_IO() won't actually
call invalidate_inode_pages2_range(), because mapping->nrpages is usually
zero.
Well, it would have been, back in the days when we were invalidating the
whole file. Now are more efficient and we only invalidate the specific
segment of that file. So if there's a stray pagecache page somewhere at the
far end ofthe file, we'll pointlessly call invalidate_inode_pages2_range() every
time. Oh well.
next prev parent reply other threads:[~2006-10-04 23:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-04 17:04 [patch] call truncate_inode_pages in the DIO fallback to buffered I/O path Jeff Moyer
2006-10-04 17:25 ` Andrew Morton
2006-10-04 17:51 ` Zach Brown
2006-10-04 17:53 ` Jeff Moyer
2006-10-04 18:16 ` Andrew Morton
2006-10-04 18:40 ` Zach Brown
2006-10-04 19:16 ` Andrew Morton
2006-10-04 20:53 ` Jeff Moyer
2006-10-04 21:22 ` Jeff Moyer
2006-10-04 23:55 ` Andrew Morton [this message]
2006-10-05 19:31 ` Jeff Moyer
2006-10-06 20:11 ` Andrew Morton
2006-10-11 16:48 ` jmoyer
2006-10-11 18:37 ` Andrew Morton
2006-10-12 22:01 ` Jeff Moyer
2006-10-12 22:37 ` Andrew Morton
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=20061004165504.c1dd3dd3.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zach.brown@oracle.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