From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) (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 C372A215055 for ; Mon, 12 Jan 2026 14:50:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768229428; cv=none; b=YM3EUbRjeuiw3iVMtB+zYrPMP6aRabzKGXixRN7OICFJxNCeilc6o2nTe9+AtbwRIcINGvB+X5xVsnjzR68QFcANlSCbexx/PfZcbQNQpGcNF3y3N8xGC0wgE9P7FIXONxeGJBFwYyooC6FCctjc3VpcIcZPEv8HLm0NwSgMSwA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768229428; c=relaxed/simple; bh=B95nz38B24DT+ExQyFEnYP4FZQcpvry7fX+6VWUnB2E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lBBJn0wEI8MWHHY/krTnDsxHEV26zY4yas+dkNqE/UK3X5NO7wd9PwtQuGuzVUA+FhJNoHA+aam3/GU6MeR2q/1jcjNpR0lyhSU6Qotr/GPDXRtfn3p5+qi0YUWrNtLu1cZmqUvWdeEHWFPQf4phzuknljb85fXgXCkhHI0nBCs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=ouwhG2Z5; arc=none smtp.client-ip=209.85.219.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="ouwhG2Z5" Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-88a26ce6619so68391156d6.3 for ; Mon, 12 Jan 2026 06:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1768229424; x=1768834224; 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=Cnr4qVR4p/JzbP4MQjfizXV7qnol5umPh39xUTusdVc=; b=ouwhG2Z5DHrMO8U9nwAey05DNz1kwh/2UJ4zO+x5YLJ8GMf3ePO0tN174G/Xv23/L+ mbKcPeuQm22GCIiRfDm592T3/oan+53aMW+kCYC3AfdLfJhyOvlfvcu7GiA+b8Hxe1AT T7RB9zAcE0favYSb4LJiyqjAWCfzjKhzviDf3zonXn6LMopC8xABRkC/uT/68ruNA6fW CDzVYRS1QXINbBiC6gHz6sEhibGzNqcKNURaPOLwMooCnB9Faj28ZloYGzWO9Gj7ObCY h8isTY/E5VPGt6Gq6qpMHoJG3Ms8PsEysvEYyIX5uUWNKnrNwnvcEOQNILfBikeogNoV s26Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768229424; x=1768834224; 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=Cnr4qVR4p/JzbP4MQjfizXV7qnol5umPh39xUTusdVc=; b=PqvbPzLgQj/fCojZPaQbojfZIKxNa3BnDAwEeaLVz+82krhC+P7oQz//J6VD0gWQ85 QLJb06GrMGQR4HgnnE/n4vdL6DB7oaSk8j+DdVXf/sZxG3nQD8Veh+yKP4Heh1rkqSmL PEvvuEpMCFyK7velXtAImSnJPKdoyHw1l3smSUyI4Ql/azDVl3aC5W22Co3m2AWEpPyJ V9ZrAEdf/40RpXj0fsg9FU70YmmPBCxNa2bdTDaSSjoTWz87onpNyYJQwSBnuNcgKIXL jT9SIomOv+Pp+FKYbvbnSefeXX97DKyn9vKH50S8U1inH6i0+4YNVTybvkqDOHh2bVFJ y2UQ== X-Forwarded-Encrypted: i=1; AJvYcCX03iNTYqrzA1jZVNQqdEq0qvTVAQAVap7BTR4xOZMUjvcSiOlwBYszU/a4photU2M/2dtKm6ode/g2mYo=@vger.kernel.org X-Gm-Message-State: AOJu0Yz2guvh0c+vBra33Ej6AL+G364U9GLA+wwnqSX1MWMsgTErPryd fQEScyN62+SA3u4Gbet/PxKmw/cjpkxmFXcv6NgGxf+ITjmTFkvV11xDQqPY0NLL/tM= X-Gm-Gg: AY/fxX5k9dCcZDePpkajZ8/gjutwNiidsWxXmgzO05COf0A9ith5QD7KlMnfLB7zRmI 4ukHajQ+Ffe8QoXdKfdXszzIpyg1FP4T3rqVobD875ERTn0SQW3SHCtCms0DwV0m8FWd5oxuOSo gJZuplp1mwchHQvuAbVrtBYlPT73gnFakzg/oJmuHwxJnSLSoBjN3RmtpFf3xfLBDIrONVVXpW/ 6TgEguiF7Z9mADV2Wy/Z11bo160e0cpgKDny9FtLHMPYSlN1RYgVdNTZFVAD9GCyBHBgxykTBm6 OANFmDCLoQSYPzX6SzpFPycze/O1D903hTC1Oqy5kMVzBQU7PSb1uqa9k5ah5Tl1OXmN7u2F9FC afb6xPX5VFcPPIIzEtdMvkceHI2FluIStSQ47Uv+11bTtzckBJBkmUkQOBf1tn3jDXtW7+tas+V 5aMslDFEmDJw== X-Google-Smtp-Source: AGHT+IGBr6wZA0PL0dSsYUFTm1Un0FAtEx8rRBSFF04sT2EzD4Qp/fT8gC2DFyR28E5Zh7N/xNhuuA== X-Received: by 2002:ad4:4ee3:0:b0:888:4932:1476 with SMTP id 6a1803df08f44-890842fb0efmr257342796d6.70.1768229424351; Mon, 12 Jan 2026 06:50:24 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-89077235411sm144888136d6.29.2026.01.12.06.50.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 06:50:23 -0800 (PST) Date: Mon, 12 Jan 2026 09:50:19 -0500 From: Johannes Weiner To: Yajun Deng 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 Subject: Re: [PATCH v2] mm/page_alloc: Avoid duplicate NR_FREE_PAGES updates in move_to_free_list() Message-ID: References: <20260112121614.1840607-1-yajun.deng@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: <20260112121614.1840607-1-yajun.deng@linux.dev> On Mon, Jan 12, 2026 at 08:16:14PM +0800, Yajun Deng wrote: > In move_to_free_list(), when a page block changes its migration type, > 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 zero > in most cases. > > 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. > > The optimization avoid duplicate NR_FREE_PAGES updates in > move_to_free_list(). > > Signed-off-by: Yajun Deng > Suggested-by: Joshua Hahn I'm not a fan of this. The code ends up more complicated, more lines, and fragile because the accounting decisions are now spread out over multiple places (again). 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. Simplicity & maintainability trumps here, IMO, unless you have hard data showing this is worth the pain.