linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Shyam Prasad N <nspmangalore@gmail.com>,
	 lsf-pc@lists.linux-foundation.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	 linux-mm@kvack.org, brauner@kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	 David Howells <dhowells@redhat.com>,
	Jeff Layton <jlayton@redhat.com>,
	Steve French <smfrench@gmail.com>,
	 trondmy@kernel.org
Cc: Shyam Prasad N <sprasad@microsoft.com>
Subject: Re: [LSF/MM/BPF TOPIC] Predictive readahead of dentries
Date: Tue, 14 Jan 2025 10:59:46 -0500	[thread overview]
Message-ID: <a143314b5751bc437fd16765ac1608b1210671fa.camel@HansenPartnership.com> (raw)
In-Reply-To: <CANT5p=rxLH-D9qSoOWgjYeD87uahmZJMwXp8uNKW66mbv8hmDg@mail.gmail.com>

On Tue, 2025-01-14 at 09:08 +0530, Shyam Prasad N wrote:
> The Linux kernel does buffered reads and writes using the page cache
> layer, where the filesystem reads and writes are offloaded to the
> VM/MM layer. The VM layer does a predictive readahead of data by
> optionally asking the filesystem to read more data asynchronously
> than what was requested.
> 
> The VFS layer maintains a dentry cache which gets populated during
> access of dentries (either during readdir/getdents or during lookup).
> This dentries within a directory actually forms the address space for
> the directory, which is read sequentially during getdents. For
> network filesystems, the dentries are also looked up during
> revalidate.
> 
> During sequential getdents, it makes sense to perform a readahead
> similar to file reads. Even for revalidations and dentry lookups,
> there can be some heuristics that can be maintained to know if the
> lookups within the directory are sequential in nature. With this, the
> dentry cache can be pre-populated for a directory, even before the
> dentries are accessed, thereby boosting the performance. This could
> give even more benefits for network filesystems by avoiding costly
> round trips to the server.

If your theory were correct, especially the bit about using the dentry
cache to retain the readahead information, wouldn't a precursor
actually be populating the dentry cache on iterate_dir() which is the
engine for both the readdir() and getdents() syscalls?  It strikes me
the reason we don't do dentry population here is partly because the
lookup() on each name would slow everything down (iterate_dir is very
locking light weight because it needs to be fast) and partly because
whatever is doing the directory read may only be interested in a single
name.  The only userspace operation you can guarantee is going to do a
lookup() for every name is ls -l, but that doesn't seem to be a good
one to optimize for.

Regards,

James



  parent reply	other threads:[~2025-01-14 15:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-14  3:38 Shyam Prasad N
2025-01-14 12:39 ` [Lsf-pc] " Jan Kara
2025-01-15  9:52   ` Shyam Prasad N
2025-01-14 13:24 ` Amir Goldstein
2025-01-14 14:12   ` Benjamin Coddington
2025-01-14 15:01     ` Paulo Alcantara
2025-01-15 14:30       ` Shyam Prasad N
2025-01-15 14:47         ` Paulo Alcantara
2025-01-15 11:27   ` Shyam Prasad N
2025-01-15 14:21     ` Amir Goldstein
2025-01-20 21:26   ` Benjamin Coddington
2025-01-14 15:59 ` James Bottomley [this message]
2025-01-16  4:50 ` Al Viro
2025-01-16  5:31 ` Christoph Hellwig

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=a143314b5751bc437fd16765ac1608b1210671fa.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=brauner@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=nspmangalore@gmail.com \
    --cc=smfrench@gmail.com \
    --cc=sprasad@microsoft.com \
    --cc=trondmy@kernel.org \
    --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