From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DDED37C113 for ; Fri, 19 Dec 2025 18:17:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766168267; cv=none; b=r7vhHhx2EEa52tew7EE4Wg7ATUUndv0hd6482TdYsaimfWcDgzNUJwZOAQ8IWY5niEScPVhf1ECPqmlVHjkHf0r8K0vQHTmDMUp4v4Q79wlijUXN7xUNB8Ntht4w0rFsuiwMXo98oawTIFYtSIME5AFqaWm/gCSPgvGleZC6PXs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766168267; c=relaxed/simple; bh=O60+zSbJ7p8sIdTeBPhfaZWOBNZGLC3nQqP0QV0wLu8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kX9NIgph9jxa7e59hkbkXXvS3hY14IsXDdWVofzgQnrCRUMmrlsbLaDovPVDrVYZLJ27/168QkzFiw4wLhkJybLm010StHZYl65jJEbIFIBRiC1ZR8mJ9nMTUitt7yURyNxI/vgFR/8KdHSw7dRUSdGG0+xEa1NYZWevXcr6v14= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=s1wMwO/2; arc=none smtp.client-ip=209.85.160.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="s1wMwO/2" Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-4f1b212ba25so17361941cf.2 for ; Fri, 19 Dec 2025 10:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1766168262; x=1766773062; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=25Nxn7S4ZrPxgXaTUt8/8ZR8LkJP8cPlzufs9a024sI=; b=s1wMwO/2gW1WGLFLGQVqOOxAkQzF9oZ+5lqHnuAB5wDOBIQwbd5p0e+XDvdxK2/kVs uaMZ3t1qPiIR0VVbc4C2s1KBUuhM8S17l7wkolpjBfo+Njeth9IVzqWZBW26J9SV9IyC KmTuHgPNabYA05d6UT3MTSQ7MDEfxPZuTnUWcPlXpcl92a8Ak2WS3wz+CLqwHP+e7x7G o0OJywNTuA/Cs9EKcg16VEnjPlYwJSRl8fQL/Je+lfaRep1Kgui6pYQDbvtPi/ink171 KMG2xWm8eLBELf/fQyIwOucjjzEKseK5iO5dTPgMqZzuYNQbHPaK6h4AlqzZTZQkOLrG HpZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766168262; x=1766773062; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=25Nxn7S4ZrPxgXaTUt8/8ZR8LkJP8cPlzufs9a024sI=; b=fJIokbDzdaxRN6TcZgRnW+vouUuQAp48q/pppv355DEmg40MeUrsexUN3D108fF/KA cEbSqNEuDaBO400hu17Xd2TKFGtuaHtwELxxGKcMgkmukpLjDulb/o6QQGNdiBu6ZlWd 0plhPyHUHTvU26kJT3y/56p2x5FCerlun3vX+OTNYI4WTUNZydTllbYtmXDfK88Xc96S U3zwLkGkCGP7Af/6LAPAUhszk1F7QQbs07pZ/ddvEVjH1fNL5XIiAC/GwTnUMxc0gIlF 1h1ZCeTgx09pAqrWGvE7IF/JqMGJjPkVPTTIB8oeviJdDYYNlgs8oHg1fXg6h7bb7s/r gfOQ== X-Forwarded-Encrypted: i=1; AJvYcCXRO5d+pJNK4jdPX6yP25yyYsYvBOuMfjnADgBIvsYB4SuRZM+Rg3oN28x/1DZRrfIXFZsGKA4JN4dYvRU=@vger.kernel.org X-Gm-Message-State: AOJu0YyXZAtptiZabmqDiKHmaclijkNcRDjNPu55FW+vEWiB3YowhPSF e5d6bAld1zMWKNtjG2xsWFWs7nw7LLoOdUHrRwWns7sh1vmxn/xrpB3Prbg3itPVsfo= X-Gm-Gg: AY/fxX40KbSpzYM2f6l/s5FBQ1lpHsp5TVkrGOkPKZBV/HfTw8DDO2ra1lmF38qwN9J z8NRXSMGJh2x71vq6YFNqG5WmvaWT+iPiKMEOHt8vZQ24yJLH8EIa25jHBaxbweCKhiVUBBHdrL RcpiSJrLoo7mNxrblkxgTREar8LpJsozurdBV3J09NOc1/4CRdPcKVGyI0vaSQZak/FlhMNhnl0 9akuGEbdk/DlqE4gNZwpYEIFHMwMC8tcbCEA48Hp/lL1edGmthwUkUPwpxZKIW0NePtGPMr2CiT TnWzS4xVY/BlyYKKDu7yR7alcAEhCzIfTFk19aVc2LZqEzjksUCSkEARo9UDPYreL1TxK7X+PoF OXL/njuBuQ6aBuD16I8BLQuH0MnrldP5ITsEFnWtzSYcaWpNKblF2Ub0oGAOStcV+iUbbONx1fW 7tLnldMsS2QI9fWO4Q98+dmtdgwU8sUjvIHxFGcq5u8ysvM8/1ApKtnq2f+LFwrPV7zSlR4A== X-Google-Smtp-Source: AGHT+IF0gYf3nQ4VOxohCT8XCqBK3I81oOq0wI0PXWLv8zlad6o6AnkQGLlpRe25NrPXHzjn0M4qyA== X-Received: by 2002:ac8:5a4c:0:b0:4f1:ab28:d9f6 with SMTP id d75a77b69052e-4f4abd03195mr53240571cf.26.1766168261524; Fri, 19 Dec 2025 10:17:41 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4f4ac66865asm23376721cf.31.2025.12.19.10.17.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Dec 2025 10:17:40 -0800 (PST) Date: Fri, 19 Dec 2025 13:17:03 -0500 From: Gregory Price To: Gladyshev Ilya Cc: patchwork@huawei.com, guohanjun@huawei.com, wangkefeng.wang@huawei.com, weiyongjun1@huawei.com, yusongping@huawei.com, leijitang@huawei.com, artem.kuzin@huawei.com, stepanov.anatoly@huawei.com, alexander.grubnikov@huawei.com, gorbunov.ivan@h-partners.com, akpm@linux-foundation.org, david@kernel.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, ziy@nvidia.com, harry.yoo@oracle.com, willy@infradead.org, yuzhao@google.com, baolin.wang@linux.alibaba.com, muchun.song@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 2/2] mm: implement page refcount locking via dedicated bit Message-ID: References: <81e3c45f49bdac231e831ec7ba09ef42fbb77930.1766145604.git.gladyshev.ilya1@h-partners.com> 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: <81e3c45f49bdac231e831ec7ba09ef42fbb77930.1766145604.git.gladyshev.ilya1@h-partners.com> On Fri, Dec 19, 2025 at 12:46:39PM +0000, Gladyshev Ilya wrote: > The current atomic-based page refcount implementation treats zero > counter as dead and requires a compare-and-swap loop in folio_try_get() > to prevent incrementing a dead refcount. This CAS loop acts as a > serialization point and can become a significant bottleneck during > high-frequency file read operations. > > This patch introduces FOLIO_LOCKED_BIT to distinguish between a > (temporary) zero refcount and a locked (dead/frozen) state. Because now > incrementing counter doesn't affect it's locked/unlocked state, it is > possible to use an optimistic atomic_fetch_add() in > page_ref_add_unless_zero() that operates independently of the locked bit. > The locked state is handled after the increment attempt, eliminating the > need for the CAS loop. > Such a fundamental change needs additional validation to show there's no obvious failures. Have you run this through a model checker to verify the only failure condition is the 2^31 overflow condition you describe? A single benchmark and a short changelog is leaves me very uneasy about such a change. ~Gregory