From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) (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 1FF51500940 for ; Sun, 11 Jan 2026 13:48:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768139288; cv=none; b=eO0YXi4fQ3eYiw/+iwhxf7BWRy/Sl9n7AAAv9NJSEwL4soE5fXm+SrVaeEWPDt//L3kjBODfF6QNwZKDtfJWx7honZ/JGvR9qyiDxrWTnDGpqPSRkvOqnehI7TagFpN2mRcjjsTT33NH8GRPXVfZLMdLJpBNHE8AQXeiz1NlzmU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768139288; c=relaxed/simple; bh=4Ukypqp1EiBjTLaOtkWo8v52TqauYikp5r5YxII25Sw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=JfqwMG11aD35F9u4nrBN6x2NIZhxwPMFpWjGGGmgfDkFir3URTUsLR+sclPExvf4a22Lk3e1LrGkireaMQD2oL6PDs7zTbpoiK0sXYit5GtwlMbidSAMbQxrsypLmrkcdIc+jWWe0JK1Cdrtt6yhHcTJaHa7mfK5epaKrkmsxrw= 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=eQ4q5cC8; arc=none smtp.client-ip=95.215.58.188 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="eQ4q5cC8" Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1768139285; 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=GhSNGWrwGcmoVHVqufjOsJfDL8qTO4IvvXL+fwvztM0=; b=eQ4q5cC83tJBvzpKZF3MBf+i+UkKGmguRfiwGzD/h6Rr1i5A9wtCNKWL6nvBroApU4WvpA mTXhJ6Mx0y5WJTeqrw8B2LWVE+0/HhFdoy63Ffuo6mLXqjnU7JbNh/VptBel6anu+MElP+ AKmJH8217YCMU0/04J6gEtQZbBloDtA= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\)) Subject: Re: [PATCH] mm/page_alloc: Avoid duplicate NR_FREE_PAGES updates in move_to_free_list() X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yajun Deng In-Reply-To: <20260109163140.1605599-1-joshua.hahnjy@gmail.com> Date: Sun, 11 Jan 2026 21:47:42 +0800 Cc: akpm@linux-foundation.org, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20260109163140.1605599-1-joshua.hahnjy@gmail.com> To: Joshua Hahn X-Migadu-Flow: FLOW_OUT > 2026=E5=B9=B41=E6=9C=8810=E6=97=A5 00:31=EF=BC=8CJoshua Hahn = =E5=86=99=E9=81=93=EF=BC=9A >=20 > On Fri, 9 Jan 2026 18:51:21 +0800 Yajun Deng = wrote: >=20 >> 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. >>=20 >> This patch introduces a new function account_freepages_both() that >> updates the statistics for both old and new migration types in one = go. >> It avoids the double update of NR_FREE_PAGES by computing the net = change >> only when the isolation status changes. >>=20 >> The optimization avoid duplicate NR_FREE_PAGES updates in >> move_to_free_list(). >=20 > Hi Yajun, >=20 > I hope you are doing well, thank you for the patch! I was hoping to = better > understand the motivation behind this patch. >=20 > =46rom my perspective, I believe that the current state of the code is > not optimal, but it is also not problematic. account_freepages seems = like > a relatively cheap function (at the core, it's just some atomic = operations). > Personally I also think that semantically, the code currently makes = sense; > we are doing the accounting for the old mounttype, then for the new = mounttype, > in a way that cancels out. And given that there is still some cases = where > the work doesn't end up canceling out due to one of the mounttypes = being > MIGRATE_ISOLATE, I think that there is enough purpose in making the = two > calls to do the accounting twice. >=20 > On the other hand I think there is only one place in the codebase that > will use account_freepages_both, so it might make the burden to = understand > the code a bit higher. >=20 > What do you think? I don't have a strong stance on whether the = performance > effects are big here (if this change indeed has a big performance = implication, > then we should definitely go forth with this!) but I do believe the = current > code is quite semantically sound and more readable.=20 >=20 Hey Joshua, Thank you for sharing your thoughts.=20 I currently don=E2=80=99t have any performance data, I just noticed from = looking at the code that there may be room for optimization. You=E2=80=99re right. The original code is indeed more straightforward. = I think we can add some comments in the account_freepages_both to make it easier to understand. > Thank you again for the patch. I hope you have a great day! > Joshua