From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3EF937081A for ; Sun, 21 Jun 2026 21:50:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782078620; cv=none; b=DiCdKhJjB5iQ0YjKL+P+Y0CKL0vcrPY6+9eoUKiZ3FCHlFytdckPGSLD6TK1Qr3d7Nm4SuMs6Z3xeypEW4ihcyiQ0G5rDBudWQaVTggSTzeeNwPrOiVDKbQnfw6R18g35qyqduXmC/LxBb+uDPtwEPTIL2qzt8cYY0fdFEq7Uec= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782078620; c=relaxed/simple; bh=doNSHTrRHYssEfQUragcBWZSAT13ulgL0zLh2IJecyg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ep8vNCxk8265qnJ1WTe4irFQ6wSijb/dFv89X8NwB0ykLNztw+mtdDZbMbSfuhWjpBbPoON4yutbPxGM6dGGCv9zuNgKdTxHPe4gKK9eYs1mbjq1M5QKkN3I+Kf480Qp1O5qeKvB3kXJoKhjgm2DRWgfQptlIJpHU2mveg+yaW0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=YeC02q0E; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="YeC02q0E" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=fHjL6tTGiIVQP9xrKQ7bnGqOGrPMpxzLYz91PzYOyLU=; b=YeC02q0ErJJLrHt/SGR8KJ8GBr L43eSFqSy6W4kYgnK/hH+AgkKNy+kg+/i7tYqPAhGfl6HISUGdKjAj2xyjP6sMHz4McjLfENOFk9M itXixbOuxuJmIodnR3/Dp+gHUK4fPNZHBh7PShK/SlH8zSXyJsgeG7KMtc349+pVUO9EfgaGfOIS/ zhOiRr1VeHkvEHDPojJKHs7v7Gf+lH6ZV7mNXP2OX4jBadZFPMnpkEf4AAxcerCpfjK5TRxpodfHW 4iRtzscvj5hA5OYGQKnYsdyVjyNF88SeemhQeqAL+QYk72vQM6bckkBWhlnlSNf/8s9auAW6dcP4O 1LALhF1w==; Received: from willy by casper.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1wbQ3F-000000033NY-3wfs; Sun, 21 Jun 2026 21:50:02 +0000 Date: Sun, 21 Jun 2026 22:50:01 +0100 From: Matthew Wilcox To: Gladyshev Ilya Cc: Linus Torvalds , Andrew Morton , 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 Message-ID: References: <20260608154734.8e4115fde4e2e14a3b6892fb@linux-foundation.org> <839a2ea2755fdddf5af773e006237b07c9e261df@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <839a2ea2755fdddf5af773e006237b07c9e261df@linux.dev> 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, 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? > T2: *normally works with this page* > T2: frees page [1 -> 0 -> FROZEN] > T2: calls dtor for type X, returns into the allocator > > ... T3 reuses the page, T1 wakes up and conflicts ... > > T1 basically needs to sleep for a veeery long time to miss full T2 & T3 > execution. > > > I didn't go back and look at the series, but isn't the rule that the code does: > > > > - optimistic get > > > > - then check that the folio is still valid (*not* using the page > > count, but by re-looking it up elsewhere, typically the address space > > mapping) > > > > - put the page if it wasn't valid > > > > - if it goes to zero, there's no destructor inherent in that > > > > - everybody who sees it go to zero - optimistic or not - does the > > "zero to frozen" cmpxchg > > The problem is -- the zero you've seen and zero you are trying to CAS > can be different zeros if the page gets reused fast enough. > (Or couldn't and I am just confused :) ) > > > - only *one* of those will succeed, and *THAT* triggers the destructor > > > > > > IOW, the transition to zero is not special per se and has no > > destructor. All it triggers is the "now we try to mark it frozen" > > phase. > > > > At least that was my mental picture. > > > > Was I wrong? Am I just confused? Wouldn't be the first time. > > > > Linus > >