The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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.

  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