From: "Ilya Gladyshev" <ilya.gladyshev@linux.dev>
To: "Matthew Wilcox" <willy@infradead.org>
Cc: "Linus Torvalds" <torvalds@linuxfoundation.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
ivgorbunov@me.com, Liam.Howlett@oracle.com, apopple@nvidia.com,
artem.kuzin@huawei.com, baolin.wang@linux.alibaba.com,
david@kernel.org, foxido@foxido.dev, harry.yoo@oracle.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
lorenzo.stoakes@oracle.com, mhocko@suse.com,
muchun.song@linux.dev, rppt@kernel.org, surenb@google.com,
vbabka@suse.cz, yuzhao@google.com, ziy@nvidia.com,
pfalcato@suse.de, kirill@shutemov.name
Subject: Re: [PATCH v4 0/2] mm: improve folio refcount scalability
Date: Tue, 23 Jun 2026 21:23:32 +0000 [thread overview]
Message-ID: <b8b444637f51df57762ddebf8ac3c515d3ba2262@linux.dev> (raw)
In-Reply-To: <ajhcia0BKmTS6FQG@casper.infradead.org>
>
> On Sun, Jun 21, 2026 at 09:34:47PM +0000, Gladyshev Ilya wrote:
>
> >
> > June 21, 2026 at 7:46 AM, Linus Torvalds wrote:
> >
> > On Sat, 20 Jun 2026 at 11:19, <ilya.gladyshev@linux.dev> wrote:
> >
> > >
> > > T2: optimistic get() [0 -> 1]
> > > T2: put page back [1 -> 0]
> > > T2: calls dtor for type X, returns into the allocator
> > >
> > Which optimistic getter does this?
> >
> > If I understood you correctly, you are talking about the scenario where
> > an optimistic getter took a refcount on the stolen page, so the validity
> > check in the XArray will fail. And this scenario does indeed work normally.
> >
> > This "ABA" happens if the optimistic getter successfully gets a refcount
> > on a valid page, so the full T2 execution looks like this:
> >
> > T2: optimistic get() [0 -> 1]
> > T2: re-checks page [OK]
> >
> I don't think that can happen. Or maybe it can and we need to add
> some barriers. The page is always removed from visibility (whether
> we're talking about a page cache lookup or a page table lookup), then
> the refcount is decremented. I hope we have enough barriers in place
> to ensure that the refcount decrement is observed after the removal of
> the PTE entry or the XArray entry.
>
> But I'm not sure why the folio_put() after a speculative get avoids this
> problem; why do we need the recheck to be successful to hit this race?
After additional thought, this race doesn't require speculative gets at all
and is more about two parallel `folio_puts()`: one successfully deallocates
the page, and one sleeps for a long time and then calls __folio_put() on a
"logically new" page.
And as everybody pointed out, this race isn't something specific to this patch.
So folio_put() was always ready to be called on non-folio objects due to
optimistic try_get() + put() in the filecache. We only care about calling
folio_put() once, and nothing breaks with this patch.
So thanks to you, Linus, and David, for helping to clarify this :) I'll post
v5 with more or less cosmetic fixes from the AI review then.
next prev parent reply other threads:[~2026-06-23 21:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 21:53 [PATCH v4 0/2] mm: improve folio refcount scalability Gladyshev Ilya
2026-06-08 21:54 ` [PATCH v4 1/2] mm: drop page refcount zero state semantics ilya.gladyshev
2026-06-08 21:54 ` [PATCH v4 2/2] mm: implement page refcount locking via dedicated bit Gladyshev Ilya
2026-06-08 22:47 ` [PATCH v4 0/2] mm: improve folio refcount scalability Andrew Morton
2026-06-09 10:28 ` David Hildenbrand (Arm)
2026-06-09 19:02 ` Gladyshev Ilya
2026-06-09 21:02 ` Pedro Falcato
2026-06-20 18:19 ` ilya.gladyshev
2026-06-21 1:40 ` Zi Yan
2026-06-22 7:55 ` David Hildenbrand (Arm)
2026-06-21 4:46 ` Linus Torvalds
2026-06-21 21:34 ` Gladyshev Ilya
2026-06-21 21:50 ` Matthew Wilcox
2026-06-23 21:23 ` Ilya Gladyshev [this message]
2026-06-21 22:53 ` Linus Torvalds
2026-06-22 8:15 ` David Hildenbrand (Arm)
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=b8b444637f51df57762ddebf8ac3c515d3ba2262@linux.dev \
--to=ilya.gladyshev@linux.dev \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=artem.kuzin@huawei.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=foxido@foxido.dev \
--cc=harry.yoo@oracle.com \
--cc=ivgorbunov@me.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=torvalds@linuxfoundation.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=yuzhao@google.com \
--cc=ziy@nvidia.com \
/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