Linux NFS development
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: David Wysochanski <dwysocha@redhat.com>
Cc: Daire Byrne <daire@dneg.com>, linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: /proc/PID/io/read_bytes accounting regression?
Date: Fri, 17 Feb 2023 14:36:51 +0000	[thread overview]
Message-ID: <Y++RA7YXtymaQJ05@casper.infradead.org> (raw)
In-Reply-To: <CALF+zO=e+d3sdLA4MZ_-SZh3epWBKF=hY=8FB+aB8+H4rxe4KA@mail.gmail.com>

On Fri, Feb 17, 2023 at 09:08:27AM -0500, David Wysochanski wrote:
> On Fri, Feb 17, 2023 at 6:56 AM Daire Byrne <daire@dneg.com> wrote:
> > On newer kernels, it looks like the task io accounting is not
> > incrementing the read_bytes when reading from a NFS mount? This was
> > definitely working on v5.16 downwards, but has not been working since
> > v5.18 up to v6.2 (I haven't tested v5.17 yet).
> 
> In v5.16 we had this call to task_io_account_read(PAGE_SIZE); on line 109
> of read_cache_pages();
> 
> But there's no call to task_io_account_read() anymore in the new
> readahead code paths that I could tell,
> but maybe I'm missing something.
> 
> Willy,
> Does each caller of readahead_page() now need to call
> task_io_account_read() or should we add that into
> readahead_page() or maybe inside read_pages()?

I think the best way is to mimic what the block layer does as closely as
possible.  Unless we can pull it out of the block layer & all
filesystems and put it in the VFS (which we can't; the VFS doesn't
know which blocks are recorded by the filesystem as holes and will not
result in I/O).

The block layer does it as part of the BIO submission path (and also
counts PGPGIN and PGPGOUT, which no network filesystems seem to do?)
You're more familiar with the NFS code than I am, so you probably
have a better idea than __nfs_pageio_add_request().

  reply	other threads:[~2023-02-17 14:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17 11:54 /proc/PID/io/read_bytes accounting regression? Daire Byrne
2023-02-17 14:08 ` David Wysochanski
2023-02-17 14:36   ` Matthew Wilcox [this message]
2023-02-17 15:47     ` David Wysochanski
2023-02-17 15:54       ` David Wysochanski
2023-02-17 15:59       ` Matthew Wilcox
2023-03-23 17:56         ` David Wysochanski

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=Y++RA7YXtymaQJ05@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=daire@dneg.com \
    --cc=dwysocha@redhat.com \
    --cc=linux-nfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox