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 D2FA020DD48 for ; Sun, 11 Jan 2026 14:50:18 +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=1768143021; cv=none; b=qDkKbwpUHAPyphVgGCshx8f7CgL+/V27geEs/jQT+tL5QXBd6H5uzn6S260H1eWiseY+bCWeNGoIa5Udwqzn1fpoKhOnYKqNwpVmOyf2cxVDRhT0wIrXcKZZVoysfgZP3gQdd8RKONrBTEvvrmL4EJ4fRHVLI1VLdpjXZE6Pm3o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768143021; c=relaxed/simple; bh=DeC0glJnKZ9nmxVIN6iqkOkhvnAzhypOXsY4LMme9+M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=a0E0An/k8AybgcPAzBwkTYYqEeyywI2oEm8SqA1Yu87vb0isPrEAU5zZmse2J27clNSx0kZ6UlYKWU1H3GcqBD6cZizjOLOwIVmoBCK1KxzA8c2BxEoioD6fYhMVx1Nkki3eXGkhbFU4NLAAodP+e0g43RDHfOEZFrnYiRm/nPg= 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=ogz8ajsW; 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="ogz8ajsW" Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1768143016; 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=3k0f9P6o12I/Wj1ZSwaN2QKUNhSwH+5PojpXHVPsDpI=; b=ogz8ajsWj76Y1EcW8pmpV6YOcpuseqfgaEmbwASTVcFr99DG4rpEO61d9x9S3BB1zeSzUa VQIEz+lUMwYfZAnBDkW655pA0+vtvLextk5Q1DeFCJKOa/K7SpvhrkInRfgbDl2+UQguSA mBsMYFs5RO6dxlAWwsPCZvR0YMLD34Q= 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: <20260111142425.2783953-1-joshua.hahnjy@gmail.com> Date: Sun, 11 Jan 2026 22:49:56 +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: <20260111142425.2783953-1-joshua.hahnjy@gmail.com> To: Joshua Hahn X-Migadu-Flow: FLOW_OUT > 2026=E5=B9=B41=E6=9C=8811=E6=97=A5 22:24=EF=BC=8CJoshua Hahn = =E5=86=99=E9=81=93=EF=BC=9A >=20 > On Sun, 11 Jan 2026 21:47:42 +0800 Yajun Deng = wrote: >=20 >>=20 >>=20 >>> 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, >>=20 >> Thank you for sharing your thoughts.=20 >>=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. >=20 > Hi Yajun, I hope you are doing well! >=20 > On second thought, I did notice that at the end of move_to_free_list, = we have > some additional conditionals that depend on the migratetype of the = mounttypes. >=20 > What if we open-code the account_freepages_both, and skip doing the > isolation checks twice? Your idea to use the ternary operator gave me = this idea! >=20 > @@ -869,14 +877,17 @@ static inline void move_to_free_list(struct page = *page, struct zone *zone, >=20 > list_move_tail(&page->buddy_list, &area->free_list[new_mt]); >=20 > - account_freepages(zone, -nr_pages, old_mt); > - account_freepages(zone, nr_pages, new_mt); > - > - if (order >=3D pageblock_order && > - is_migrate_isolate(old_mt) !=3D = is_migrate_isolate(new_mt)) { > - if (!is_migrate_isolate(old_mt)) > - nr_pages =3D -nr_pages; > - __mod_zone_page_state(zone, NR_FREE_PAGES_BLOCKS, = nr_pages); > + if (!old_isolated) > + account_specific_freepages(zone, -nr_pages, old_mt); > + if !(new_isolated) > + account_specific_freepages(zone, nr_pages, new_mt); > + > + if (old_isolated !=3D new_isolated) { > + nr_pages =3D old_isolated ? nr_pages : -nr_pages; > + __mod_zone_page_state(zone, NR_FREE_PAGES, nr_pages); > + if (order >=3D pageblock_order) > + __mod_zone_page_state(zone, = NR_FREE_PAGES_BLOCKS, > + nr_pages); > } > } >=20 > I don't think it matters that we reorder the __mod_zone_page_state to = be > after the account_specific_freepages here, so hopefully it is OK here. >=20 > So we can achieve the best of both worlds by preventing the duplicate = adjustment > and also keep the control flow simple! (We can also just include that > additional check inside your account_freepages_both as well). >=20 > This is just my small idea : -) Of course, please feel free to ignore = it if > you feel that it makes the code more confusing. I think that what is = "simple" > is mostly subjective, so this was just my thought. >=20 I think this is a good idea and I will adopt it. Thank you > Thank you for your thoughts, I hope you have a great day! > Joshua