All of lore.kernel.org
 help / color / mirror / Atom feed
From: riteshh <riteshh@linux.ibm.com>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: David Howells <dhowells@redhat.com>,
	linux-fsdevel@vger.kernel.org, Brendan Gregg <bgregg@netflix.com>
Subject: Re: [PATCH 0/3] readahead improvements
Date: Thu, 8 Apr 2021 16:27:05 +0530	[thread overview]
Message-ID: <20210408105705.exod2cvtvnr4467o@riteshh-domain> (raw)
In-Reply-To: <20210407201857.3582797-1-willy@infradead.org>

On 21/04/07 09:18PM, Matthew Wilcox (Oracle) wrote:
> As requested, fix up readahead_expand() so as to not confuse the ondemand
> algorithm.  Also make the documentation slightly better.  Dave, could you
> put in some debug and check this actually works?  I don't generally test
> with any filesystems that use readahead_expand(), but printing (index,
> nr_to_read, lookahead_size) in page_cache_ra_unbounded() would let a human
> (such as your good self) determine whether it's working approximately
> as designed.

Hello,

Sorry about the silly question here, since I don't have much details of how
readahead algorithm code path.

1. Do we know of a way to measure efficiency of readahead in Linux?
2. And if there is any way to validate readahead is working correctly and as
   intended in Linux?
Like is there anything designed already to measure above two things?
If not, are there any stats which can be collected and later should be parsed to
say how efficient readahead is working in different use cases and also can
verify if it's working correctly?

I guess, we can already do point 1 from below. What about point 2 & 3?
1. Turn on/off the readahead and measure file reads timings for different
   patterns. - I guess this is already doable.

2. Collecting runtime histogram showing how readahead window is
   increasing/decreasing based on changing read patterns. And collecting how
   much IOs it takes to increase/decrease the readahead size.
   Are there any tracepoints needed to be enabled for this?

3. I guess it won't be possible w/o a way to also measure page cache
   efficiency. Like in case of a memory pressure, if the page which was read
   using readahead is thrown out only to re-read it again.
   So a way to measure page cache efficiency also will be required.

Any idea from others on this?

I do see below page[1] by Brendan showing some ways to measure page cache
efficiency using cachestat. But there are also some problems mentioned in the
conclusion section, which I am not sure of what is the latest state of that.
Also it doesn't discusses much on the readahead efficiency measurement.

[1]: http://www.brendangregg.com/blog/2014-12-31/linux-page-cache-hit-ratio.html


  parent reply	other threads:[~2021-04-08 10:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07 20:18 Matthew Wilcox (Oracle)
2021-04-07 20:18 ` [PATCH 1/3] mm/filemap: Pass the file_ra_state in the ractl Matthew Wilcox (Oracle)
2021-04-07 20:18 ` [PATCH 2/3] fs: Document file_ra_state Matthew Wilcox (Oracle)
2021-04-07 20:18 ` [PATCH 3/3] mm/readahead: Adjust file_ra in readahead_expand Matthew Wilcox (Oracle)
2021-04-07 22:43 ` [PATCH 0/3] readahead improvements David Howells
2021-04-08 10:57 ` riteshh [this message]
2021-04-08 13:15   ` Brendan Gregg
2021-04-08 12:51 ` [PATCH] mm, netfs: Fix readahead bits David Howells
2021-04-08 13:09   ` Matthew Wilcox

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=20210408105705.exod2cvtvnr4467o@riteshh-domain \
    --to=riteshh@linux.ibm.com \
    --cc=bgregg@netflix.com \
    --cc=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=willy@infradead.org \
    --subject='Re: [PATCH 0/3] readahead improvements' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.