[GIT PULL] orangefs pull request for 5.13

[GIT PULL] orangefs pull request for 5.13

[Mike Marshall]

The following changes since commit acd3d28594536e9096c1ea76c5867d8a68babef6:

  Merge tag 'fixes-v5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
(2021-04-27 19:32:55 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux.git
tags/for-linus-5.13-ofs-1

for you to fetch changes up to 211f9f2e0503efa4023a46920e7ad07377b4ec58:

  orangefs: leave files in the page cache for a few micro seconds at
least (2021-04-29 08:06:05 -0400)

----------------------------------------------------------------
orangefs: implement orangefs_readahead

mm/readahead.c/read_pages was quite a bit different back
when I put my open-coded readahead logic into orangefs_readpage.
It seemed to work as designed then, it is a trainwreck now.

This patch implements orangefs_readahead using new xarray
and readahead_expand features that have just been pulled and
removes all my open-coded readahead logic.

This patch results in an extreme read performance improvement,
these sample numbers are from my test VM:

Here's an example of what's upstream in
5.11.8-200.fc33.x86_64:

30+0 records in
30+0 records out
125829120 bytes (126 MB, 120 MiB) copied, 5.77943 s, 21.8 MB/s

And here's this version of orangefs_readahead on top of
5.12.0-rc4:

30+0 records in
30+0 records out
125829120 bytes (126 MB, 120 MiB) copied, 0.325919 s, 386 MB/s

There are four xfstest regressions with this patch. David Howells
and Matthew Wilcox have been helping me work with this code. One
of the regressions has gone away with the most recent version of
their code that I'm using. I hope this patch can be
pulled even though there are still a few regressions, and that
we can try to get them resolved during the RC period.

----------------------------------------------------------------
Mike Marshall (2):
      Orangef: implement orangefs_readahead.
      orangefs: leave files in the page cache for a few micro seconds at least

 fs/orangefs/file.c         |  34 +++----------
 fs/orangefs/inode.c        | 122 +++++++++++++++++----------------------------
 fs/orangefs/orangefs-mod.c |   2 +-
 3 files changed, 54 insertions(+), 104 deletions(-)

Re: [GIT PULL] orangefs pull request for 5.13

[pr-tracker-bot]

The pull request you sent on Sun, 2 May 2021 16:45:19 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux.git tags/for-linus-5.13-ofs-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9ccce092fc64d19504fa54de4fd659e279cc92e7

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] orangefs pull request for 5.13

[Matthew Wilcox]

On Sun, May 02, 2021 at 04:45:19PM -0400, Mike Marshall wrote:
> orangefs: implement orangefs_readahead
> 
> mm/readahead.c/read_pages was quite a bit different back
> when I put my open-coded readahead logic into orangefs_readpage.
> It seemed to work as designed then, it is a trainwreck now.

Hey Mike,

I happened to have a chance to look at orangefs_readahead today, and
I'd like to suggest a minor improvement.

It's possible for rac->file to be NULL if the caller doesn't have a
struct file.  I think that only happens when filesystems call their own
readahead routine internally, but in case it might happen from generic
code in the future, I recommend you do something like ...

-       struct file *file = rac->file;
-       struct inode *inode = file->f_mapping->host;
+       struct inode *inode = rac->mapping->host;
...
-       i_pages = &file->f_mapping->i_pages;
+       i_pages = &rac->mapping->i_pages;
...
-                       inode->i_size, NULL, NULL, file)) < 0)
+                       inode->i_size, NULL, NULL, rac->file)) < 0)

(i have this change all tangled up with some other changes in my tree,
so no easy patch to apply, sorry)

Re: [GIT PULL] orangefs pull request for 5.13

[Mike Marshall]

Thanks Matthew...

I added in your changes to "the current linus tree" and ran
the whole thing through xfstests with my fingers crossed.
It didn't fix any regressions :-) but I'll send it in as a patch.

-Mike

On Sun, May 2, 2021 at 6:59 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Sun, May 02, 2021 at 04:45:19PM -0400, Mike Marshall wrote:
> > orangefs: implement orangefs_readahead
> >
> > mm/readahead.c/read_pages was quite a bit different back
> > when I put my open-coded readahead logic into orangefs_readpage.
> > It seemed to work as designed then, it is a trainwreck now.
>
> Hey Mike,
>
> I happened to have a chance to look at orangefs_readahead today, and
> I'd like to suggest a minor improvement.
>
> It's possible for rac->file to be NULL if the caller doesn't have a
> struct file.  I think that only happens when filesystems call their own
> readahead routine internally, but in case it might happen from generic
> code in the future, I recommend you do something like ...
>
> -       struct file *file = rac->file;
> -       struct inode *inode = file->f_mapping->host;
> +       struct inode *inode = rac->mapping->host;
> ...
> -       i_pages = &file->f_mapping->i_pages;
> +       i_pages = &rac->mapping->i_pages;
> ...
> -                       inode->i_size, NULL, NULL, file)) < 0)
> +                       inode->i_size, NULL, NULL, rac->file)) < 0)
>
> (i have this change all tangled up with some other changes in my tree,
> so no easy patch to apply, sorry)