From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
Linux-MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Johannes Weiner <hannes@cmpxchg.org>,
Steven Whitehouse <swhiteho@redhat.com>
Subject: Re: [PATCH] mm/filemap: do not allocate cache pages beyond end of file at read
Date: Wed, 30 Oct 2019 08:02:14 +0100 [thread overview]
Message-ID: <CAHk-=wimHFUTrEiP-m8hKi78NRoaGtwG06=Pqe3TghmsUQL9Xg@mail.gmail.com> (raw)
In-Reply-To: <20191030065037.o3q6usc5vo3woif6@box>
On Wed, Oct 30, 2019 at 7:50 AM Kirill A. Shutemov <kirill@shutemov.name> wrote:
>
> I don't know much about filesystems, but can't size of file change after
> the open() under network filesystem? Revlidation on read looks like an
> requirement anyway, no?
Requirement? No. But QoS issue, yes.
But note that NFS already does that. Look at nfs_file_read(), and
notice how it's not using generic_file_buffered_read() directly, it's
doing its own thing first with checking for direct-IO, but then doing
that nfs_revalidate_mapping() that checks whether caches should be
re-validated.
It's not just size of the file, the actual cached contents may need
invalidating too etc.
And note how the generic page cache reader doesn't need to care. If
what the generic code does isn't enough, or is the wrong thing, the
filesystem simply shouldn't use it, or, like NFS, do its own thing
first/last.
So I think the "some filesystems may have other rules" is irrelevant.
If they do have other rules, it's _their_ issue, not the issue of the
generic page cache read logic.
Linus
next prev parent reply other threads:[~2019-10-30 7:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-28 9:59 Konstantin Khlebnikov
2019-10-28 12:39 ` Linus Torvalds
2019-10-28 12:42 ` Kirill A. Shutemov
2019-10-28 12:47 ` Linus Torvalds
2019-10-28 12:57 ` Kirill A. Shutemov
2019-10-29 14:25 ` Konstantin Khlebnikov
2019-10-29 16:52 ` Linus Torvalds
2019-10-30 6:50 ` Kirill A. Shutemov
2019-10-30 7:02 ` Linus Torvalds [this message]
2019-10-30 10:34 ` Steven Whitehouse
2019-10-30 10:54 ` Linus Torvalds
2019-10-31 11:40 ` Steven Whitehouse
2019-11-22 23:59 ` Andreas Grünbacher
2019-11-25 10:52 ` Steven Whitehouse
2019-11-25 17:05 ` Linus Torvalds
2019-11-27 15:41 ` Steven Whitehouse
2019-11-27 16:29 ` Andreas Gruenbacher
2019-11-27 17:29 ` Linus Torvalds
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='CAHk-=wimHFUTrEiP-m8hKi78NRoaGtwG06=Pqe3TghmsUQL9Xg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=khlebnikov@yandex-team.ru \
--cc=kirill@shutemov.name \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=swhiteho@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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