Messages in this thread | | | Subject | Re: [PATCH] mm/filemap: do not allocate cache pages beyond end of file at read | From | Konstantin Khlebnikov <> | Date | Tue, 29 Oct 2019 17:25:27 +0300 |
| |
On 28/10/2019 15.57, Kirill A. Shutemov wrote: > On Mon, Oct 28, 2019 at 01:47:16PM +0100, Linus Torvalds wrote: >> On Mon, Oct 28, 2019 at 1:42 PM Kirill A. Shutemov <kirill@shutemov.name> wrote: >>> >>> I've tried something of this sort back in 2013: >>> >>> http://lore.kernel.org/r/1377099441-2224-1-git-send-email-kirill.shutemov@linux.intel.com >>> >>> and I've got push back. >>> >>> Apparently, some filesystems may not have valid i_size before >readpage(). >>> Not sure if it's still the case... >> >> Well, I agree that there might be some network filesystem that might >> have inode sizes that are stale, but if that's the case then I don't >> think your previous patch works either. >> >> It too will avoid the readpage() if the read position is beyond i_size. >> >> No? > > Yes. That's the reason the patch was rejected back then. > > My point is that we need to make sure that this patch not break anything. >
I think all network filesystems which synchronize metadata lazily should be marked. For example as "SB_VOLATILE". And vfs could handle them specially.
For this case generic_file_buffered_read() could call for them readpages for single page (rather than readpage) to let filesystem revalidate metadata and drop unneeded page without inserting it into inode and lru.
| |