linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shyam Prasad N <nspmangalore@gmail.com>
To: Matthew Wilcox <willy@infradead.org>,
	David Howells <dhowells@redhat.com>,
	Steve French <smfrench@gmail.com>,
	CIFS <linux-cifs@vger.kernel.org>
Subject: Classification of reads within a filesystem
Date: Wed, 21 Jul 2021 22:38:59 +0530	[thread overview]
Message-ID: <CANT5p=p+f6mrQqKULqJdbyDN-NJoQCsGruvVMH+BUJU0-n62rg@mail.gmail.com> (raw)

Hi Matthew,

I had a query about a filesystem's ability to differentiate readaheads
from actual reads.
David Howells suggested that you may be able to answer this one. If
not, please feel free to add the right people to this email.

In a scenario where a user/application issues a readahead/fadvise for
large data ranges in advance (informing the kernel that they intend to
read these data ranges soon). Depending on how much data ranges these
calls cover, it could keep the network quite busy for a network
filesystem (or the disk for a block filesystem).

I see some value if filesystems have the ability to differentiate the
reads from regular buffered reads by users. In such cases, the
filesystem can choose to throttle the readahead reads, so that there's
a specified bandwidth that's still available for regular reads.

I wanted to get your opinions about this. And whether this can be done
already in VFS ->readahead and ->readpage calls in the filesystems?

-- 
Regards,
Shyam

             reply	other threads:[~2021-07-21 17:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21 17:08 Shyam Prasad N [this message]
2021-07-21 17:52 ` Classification of reads within a filesystem Matthew Wilcox
2021-07-22  4:14   ` Christoph Hellwig
2021-07-23 10:37   ` Shyam Prasad N

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='CANT5p=p+f6mrQqKULqJdbyDN-NJoQCsGruvVMH+BUJU0-n62rg@mail.gmail.com' \
    --to=nspmangalore@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=smfrench@gmail.com \
    --cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).