From: Anders Blomdell <anders.blomdell@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Jan Kara <jack@suse.cz>, Philippe Troin <phil@fifi.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, NeilBrown <neilb@suse.de>
Subject: Re: Regression in NFS probably due to very large amounts of readahead
Date: Tue, 26 Nov 2024 18:26:13 +0100 [thread overview]
Message-ID: <569d0df0-71d5-4227-aa28-e57cd60bc9f1@gmail.com> (raw)
In-Reply-To: <Z0X9hnjBEWXcVms-@casper.infradead.org>
On 2024-11-26 17:55, Matthew Wilcox wrote:
> On Tue, Nov 26, 2024 at 04:28:04PM +0100, Anders Blomdell wrote:
>> On 2024-11-26 16:06, Jan Kara wrote:
>>> Hum, checking the history the update of ra->size has been added by Neil two
>>> years ago in 9fd472af84ab ("mm: improve cleanup when ->readpages doesn't
>>> process all pages"). Neil, the changelog seems as there was some real
>>> motivation behind updating of ra->size in read_pages(). What was it? Now I
>>> somewhat disagree with reducing ra->size in read_pages() because it seems
>>> like a wrong place to do that and if we do need something like that,
>>> readahead window sizing logic should rather be changed to take that into
>>> account? But it all depends on what was the real rationale behind reducing
>>> ra->size in read_pages()...
>>
>> My (rather limited) understanding of the patch is that it was intended to read those pages
>> that didn't get read because the allocation of a bigger folio failed, while not redoing what
>> readpages already did; how it was actually going to accomplish that is still unclear to me,
>> but I even don't even quite understand the comment...
>>
>> /*
>> * If there were already pages in the page cache, then we may have
>> * left some gaps. Let the regular readahead code take care of this
>> * situation.
>> */
>>
>> the reason for an unchanged async_size is also beyond my understanding.
>
> This isn't because we couldn't allocate a folio, this is when we
> allocated folios, tried to read them and we failed to submit the I/O.
> This is a pretty rare occurrence under normal conditions.
I beg to differ, the code is reached when there is
no folio support or ra->size < 4 (not considered in
this discussion) or falling throug when !err, err
is set by:
err = ra_alloc_folio(ractl, index, mark, order, gfp);
if (err)
break;
isn't the reading done by:
read_pages(ractl);
which does not set err!
/Anders
next prev parent reply other threads:[~2024-11-26 17:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-23 22:32 Anders Blomdell
2024-11-26 1:48 ` Philippe Troin
2024-11-26 8:01 ` Anders Blomdell
2024-11-26 10:37 ` Jan Kara
2024-11-26 12:49 ` Anders Blomdell
2024-11-26 13:24 ` Anders Blomdell
2024-11-26 15:00 ` Jan Kara
2024-11-26 15:06 ` Jan Kara
2024-11-26 15:28 ` Anders Blomdell
2024-11-26 16:55 ` Matthew Wilcox
2024-11-26 17:26 ` Anders Blomdell [this message]
2024-11-26 18:42 ` Matthew Wilcox
2024-11-26 20:22 ` Anders Blomdell
2024-11-27 7:55 ` Anders Blomdell
2024-11-27 8:37 ` NeilBrown
2024-11-27 11:06 ` Jan Kara
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=569d0df0-71d5-4227-aa28-e57cd60bc9f1@gmail.com \
--to=anders.blomdell@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=neilb@suse.de \
--cc=phil@fifi.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