From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 7021C3D0905 for ; Wed, 1 Apr 2026 22:58:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775084290; cv=none; b=t3VUBzvdm5nYXJ6k8L/AKfPm4j5fl1f9AzQKyKcWh3dymKnPY+NMXGq5aa0/LUd7z9Fkr0oXKBVrZANGV7q5VGdKIaMC9+prdCloJ4jp0BdKOY1VuWDUrwJCp//fFFi0EXp+xQeAobanjKPmg/Mw+gRHBrEon+gGU7ho3FthNTk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775084290; c=relaxed/simple; bh=5+AWPMRlp1YZ68UahL/4QgZBokb03f3laQhyvrJ4g0A=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=g/88o2gWysDE5M/WPs9tMI6CaETSSvl1cjtkVFxgtLBlFuQ8PJ1wmQaTIDTimqVEEmClElKoSAd3Qt7N9MsAZHUMuIOnMM0TrREIDtM6k7/eyc0PYvul2q5dn/FjA3Ga4ugcBmjjzuh8mDQfYg8hfXiC3obWxayod8uBhPYzMVY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=14jJpOkz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="14jJpOkz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A698C4CEF7; Wed, 1 Apr 2026 22:58:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1775084289; bh=5+AWPMRlp1YZ68UahL/4QgZBokb03f3laQhyvrJ4g0A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=14jJpOkzTzELneqtiQa3oNlQerPW00SgWQfMK4aAwJ/+X3iY3Vltwaf4Ebm3/ii4J ZqWC+ptp1pWFjlQ79UuG2SFCMDyFYYOIOJIEfeS6sKkj/i7hh8aPQEwVkNKo2JF/HQ rtd8+aDfeMyMPsxBnK6ObE4DrAfVTwGKtygwv+HQ= Date: Wed, 1 Apr 2026 15:58:08 -0700 From: Andrew Morton To: "David Hildenbrand (Arm)" Cc: David Carlier , Barry Song <21cnbao@gmail.com>, Kairui Song , Chris Li , Kemeng Shi , Nhat Pham , Baoquan He , Youngjun Park , NeilBrown , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v3] mm/page_io: use sio->len for PSWPIN accounting in sio_read_complete() Message-Id: <20260401155808.b91597fbc3c4dd1458c6ad85@linux-foundation.org> In-Reply-To: References: <20260330071229.14614-1-devnexen@gmail.com> <20260401074753.238053-1-devnexen@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Wed, 1 Apr 2026 10:32:30 +0200 "David Hildenbrand (Arm)" wrote: > On 4/1/26 09:47, David Carlier wrote: > > sio_read_complete() uses sio->pages to account global PSWPIN vm events, > > but sio->pages tracks the number of bvec entries (folios), not base > > pages. > > > > While large folios cannot currently reach this path (SWP_FS_OPS and > > SWP_SYNCHRONOUS_IO are mutually exclusive, and mTHP swap-in allocation > > is gated on SWP_SYNCHRONOUS_IO), the accounting is semantically > > inconsistent with the per-memcg path which correctly uses > > folio_nr_pages(). > > > > Use sio->len >> PAGE_SHIFT instead, which gives the correct base page > > count since sio->len is accumulated via folio_size(folio). > > > > Signed-off-by: David Carlier > > For the next time: Please don't send new revisions as reply to other > revisions :) Also, altering the Subject: causes akpm confusion (not hard). But having accurate titles is more important than avoiding akpm confusion, so there is that. A little "what i changed since v2" note after the "---" separator is helpful, please. But I figured it out! Thanks, I'll pop this into my after-rc1 pile.