From: Linus Torvalds <torvalds@linux-foundation.org>
To: Kiryl Shutsemau <kirill@shutemov.name>
Cc: Matthew Wilcox <willy@infradead.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: Optimizing small reads
Date: Fri, 3 Oct 2025 09:18:52 -0700 [thread overview]
Message-ID: <CAHk-=wgy=oOSu+A3cMfVhBK66zdFsstDV3cgVO-=RF4cJ2bZ+A@mail.gmail.com> (raw)
In-Reply-To: <flg637pjmcnxqpgmsgo5yvikwznak2rl4il2srddcui2564br5@zmpwmxibahw2>
On Fri, 3 Oct 2025 at 02:55, Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> So, you intentionally bypassing refcount bump on the folio which is part
> of the usual page cache lookup protocol.
Yes. The big cost that Willy reported originally was the cacheline
bouncing of the refcount (due to having tons and tons of very small
reads on the same page in a very threaded load).
My initial reaction was that it was a completely unrealistic
microbenchmark (who would read the same page from multiple threads at
the same time unless they were just doing some silly benchmark with no
real-world application?), but apparently there are real loads.
> But without the pin, what prevents the folio from being freed and
> reallocated in the same spot under you? Do we wait for a grace period
> somewhere in this reallocation cycle? I don't see it.
That was one of the theories and it might be the right one. There was
some discussion about having a sequence number. It's a long time ago,
I forget.
I had some reason I thought it wasn't an issue, but after all this
time I can't recall.
There's a reason that patch was marked 'Not-yet-signed-off-by' :)
Linus
next prev parent reply other threads:[~2025-10-03 16:19 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 2:18 Linus Torvalds
2025-10-03 3:32 ` Luis Chamberlain
2025-10-15 21:31 ` Swarna Prabhu
2025-10-03 9:55 ` Kiryl Shutsemau
2025-10-03 16:18 ` Linus Torvalds [this message]
2025-10-03 16:40 ` Linus Torvalds
2025-10-03 17:23 ` Kiryl Shutsemau
2025-10-03 17:49 ` Linus Torvalds
2025-10-06 11:44 ` Kiryl Shutsemau
2025-10-06 15:50 ` Linus Torvalds
2025-10-06 18:04 ` Kiryl Shutsemau
2025-10-06 18:14 ` Linus Torvalds
2025-10-07 21:47 ` Linus Torvalds
2025-10-07 22:35 ` Linus Torvalds
2025-10-07 22:54 ` Linus Torvalds
2025-10-07 23:30 ` Linus Torvalds
2025-10-08 14:54 ` Kiryl Shutsemau
2025-10-08 16:27 ` Linus Torvalds
2025-10-08 17:03 ` Linus Torvalds
2025-10-09 16:22 ` Kiryl Shutsemau
2025-10-09 17:29 ` Linus Torvalds
2025-10-10 10:10 ` Kiryl Shutsemau
2025-10-10 17:51 ` Linus Torvalds
2025-10-13 15:35 ` Kiryl Shutsemau
2025-10-13 15:39 ` Kiryl Shutsemau
2025-10-13 16:19 ` Linus Torvalds
2025-10-14 12:58 ` Kiryl Shutsemau
2025-10-14 16:41 ` Linus Torvalds
2025-10-13 16:06 ` Linus Torvalds
2025-10-13 17:26 ` Theodore Ts'o
2025-10-14 3:20 ` Theodore Ts'o
2025-10-08 10:28 ` Kiryl Shutsemau
2025-10-08 16:24 ` Linus Torvalds
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='CAHk-=wgy=oOSu+A3cMfVhBK66zdFsstDV3cgVO-=RF4cJ2bZ+A@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=kirill@shutemov.name \
--cc=linux-mm@kvack.org \
--cc=mcgrof@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