From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (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 1E2F9269CE7 for ; Tue, 13 Jan 2026 07:13:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768288425; cv=none; b=TbblbnBMWwBbO176C6Ah4RdUT+F3POnEsHamvg73RFhlS5s59ET6Gl6zmPMi9/hSIOUo0QhzUdQgJ13Sl1Q7csds9s0aw3li9J2XQv+EEkIpn98V5X7z+vjv9lz+X8yjtvxXF1qwkaBoKbB9vVrDthTff6VN3PR5Aks+TWjkCFY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768288425; c=relaxed/simple; bh=VcsMyBNK6AuqSvnVEyliGQgwpDVXXAHO4boWbMJ/m9Q=; h=MIME-Version:Date:Content-Type:From:Message-ID:Subject:To:Cc: In-Reply-To:References; b=p7GNd2xh8al2EbEPepNlo5mZscYuQbyPwli9NFUUX3mlA8/20H0DRusD+C8cHl57EEhFmCo55Vsnv+Kk79bVdIP2KCPTOU88Dh4giryo5q863AZXEbQFODwvrqQPTEGHxC3jW8MbejPZTcT6koAXOh1gvQQPXykTgsbVz2zkDF4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=R0ss3vem; arc=none smtp.client-ip=91.218.175.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="R0ss3vem" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1768288420; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Q+ZKW0GP1b7GKPfgTqUx6aEoV/9mqleFS1zBFdDBGto=; b=R0ss3vem79jr77oOiAFgGjgTmEo0vBmk+oZ9KzSSyVrsLjKmPwi4zhcCWWfB1/WczmVXx/ dExB0NiRgCH0LvFSUNKWCPk7wf4pILOruJVmNfvQLed2yFTV05XjJrzPBK4NiVHcOt5ZO1 DwLaYjssM0823dNLLQFY40S+LJ6fscY= Date: Tue, 13 Jan 2026 07:13:39 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Yajun Deng" Message-ID: <5cda8821bd3ac432a06698fa7eebdab0aff77452@linux.dev> TLS-Required: No Subject: Re: [PATCH v2] mm/page_alloc: Avoid duplicate NR_FREE_PAGES updates in move_to_free_list() To: "Johannes Weiner" Cc: akpm@linux-foundation.org, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, jackmanb@google.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Joshua Hahn" In-Reply-To: References: <20260112121614.1840607-1-yajun.deng@linux.dev> X-Migadu-Flow: FLOW_OUT January 12, 2026 at 10:50 PM, "Johannes Weiner" wrote: >=20 >=20On Mon, Jan 12, 2026 at 08:16:14PM +0800, Yajun Deng wrote: >=20 >=20>=20 >=20> In move_to_free_list(), when a page block changes its migration typ= e, > > we need to update free page counts for both the old and new types. > > Originally, this was done by two calls to account_freepages(), which > > updates NR_FREE_PAGES and also type-specific counters. However, this > > causes NR_FREE_PAGES to be updated twice, while the net change is ze= ro > > in most cases. > >=20=20 >=20> This patch adds a condition that updates the NR_FREE_PAGES only if= one of > > the two types is the isolate type. This avoids NR_FREE_PAGES being > > updates twice. > >=20=20 >=20> The optimization avoid duplicate NR_FREE_PAGES updates in > > move_to_free_list(). > >=20=20 >=20> Signed-off-by: Yajun Deng > > Suggested-by: Joshua Hahn > >=20 >=20I'm not a fan of this. >=20 >=20The code ends up more complicated, more lines, and fragile because th= e > accounting decisions are now spread out over multiple places (again). >=20 How=20about V1? It will introduce=C2=A0account_freepages_both(). https://lore.kernel.org/all/20260109105121.328780-1-yajun.deng@linux.dev/ > Is it worth it? move_to_free_list() is used in page isolation, which > has to do the accounting anyway; and migratetype fallbacks, which we > are trying to avoid as much as possible. So this path shouldn't be all > that hot to begin with. >=20 Not=20all cases are of the isolation type. There are indeed=C2=A0duplicat= e caculations. move_freepages_block() will be called in=C2=A0__isolate_free_page(). Both old_mt and new_mt are=C2=A0mergeable type in this case. > Simplicity & maintainability trumps here, IMO, unless you have hard > data showing this is worth the pain. > I'm tring to do it, but I haven't yet.