Re: Improve page refcount scalability

[Linus Torvalds]

On Wed, 14 Oct 2026 at 06:59, Pedro Falcato <pfalcato@xxxxxxx> wrote:
>
> On Tue, Oct 13, 2026 at 06:01:15PM -0700, Linus Torvalds wrote:
> >
> > So there's effectively three different things working together:
> >
> >  - mark a folio PG_rcu_free only when it's hot and keeps being accessed
> >
> >    (See commits dabc522cee5b: "mm: have folio_mark_accessed() return
> > whether the folio is hot" and  bb5908b733a1: "mm/filemap: set
> > PG_rcu_free on the folios that reads keep coming back to" for details
> > - both are pretty tiny and not really all that complicated)
>
> I'm not sure this is a good criteria for checking whether a folio should
> be RCU-ified.

So my argument really is that there is almost no downside to marking a
page for RCU freeing.

Yes, it delays the freeing, but it really doesn't make it very
expensive - and it does make reading it noticeably cheaper.

I'll argue that PG_rcu_free is cheaper than just marking a page
accessed, much less having a dirty page. A page that got marked
accessed is *also* going to make freeing it more expensive: it makes
it go through the LRU lists one more round, and you're effectively
delaying the freeing of that page. On an average machine these days,
it means that that page will be delayed to happen after many other
gigabytes of pages. But nobody even blinks an eye at *that*, do they?

And it's not even *remotely* the problem that a dirty page is, because
while it requires that "wait for RCU", it won't cause the kinds of
fundamental problems that IO causes with writeback.

So marking pages PG_rcu_free isn't "no cost", but it's a real upside
if it keeps getting read, and the cost isn't actually that bad
compared to things people don't even give a second thought to.

> - you don't need that many accesses to get an active, referenced folio. LRU
> batching makes it a little harder, but not by much.

I thing it needs  six accesses with the current mglru and default
settings as it goes from "not referenced at all" through the lru
generations and then finally hits the "no more generations => it is
hot".

Sure, if you don't do mglru you hit that final stage already on the
fourth access as it walks through "referenced", "active / ref
cleared", "active / ref set" and "no more stages => it is hot hot".

But if you read the same page six (or even just four) times, it's
clearly somethign that keeps getting accessed. So "mark it for RCU and
fast accesses in the future" doesn't sound at all aggressive,
considering how low the cost is.

> - rewinding along a folio doesn't tell you much other than the reader
> went back, for some reason. It's also natively racy so funny things like
> multiple pread()'s to the same fd can easily confuse this mechanism into
> marking this as hot.

Multiple poread()s to the same folio is exactly the case we want to trigger.

Can you make a load that marks pages active without those pages being
useful? Absolutely. But if somebody does that intentionally, they only
have themselves to blame if the end result doesn't perform well.

And if you don't do it intentionally, you have to *work* at it. The
read() logic already treats "continue from the same spot" as not being
a new access. So you really have to *actively* do silly things to
cause a page to be marked accessed six times.

Or - and hear me out - that page really was accessed several times and
should be marked for fast accesses. No?

> How many pages (as a %) are you seeing as marked PG_rcu_free across a boot/
> realistic workload?

I haven't actually checked outside of "a normal boot doesn't cause
even a single accelerated RCU period". But I'll go reboot into a clean
kernel and see what a kernel compile does.

               Linus