From nobody Thu Dec 18 23:30:08 2025 Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) (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 C0F2B34CFAD for ; Tue, 16 Dec 2025 14:27:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765895279; cv=none; b=RAuIwHMG/9CywgFFlpGjspZ7DQtOdysiw9v4nIZh3FUxJpz5Av+yHf8rVFDd7ljY2UpidQc8mbKUFbeoaLElqpTVd1yxcdzDdq5r26pYSWMIGupnECf9R+QrDrO17Sg3L9DzNPT25D1Kgg+x0JNde/ssTReGCWlFqK8+Hi0WwOc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765895279; c=relaxed/simple; bh=AsIWudNHA1cLbY/+BYwWa9v+4OBSoHK4tJatjsaaA+o=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=BdPJSK1oBSuPKh9XWWpWH5aCMxjtU4c0TF5BTRrQbn39wwkCYVHaOcN8nCs/Hufe/LYI7hVtaTmS2GDbq17tdQVuixwkYA5E8g+xXnrkLR0byJrS7CtSDLRJLnnTAx+njbxmT52DDkm00wtQo5uzwMRwLmiiVSJI78HiEIc7nb0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=fFANVyGT; arc=none smtp.client-ip=209.85.128.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fFANVyGT" Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-78c5adeb964so44971127b3.1 for ; Tue, 16 Dec 2025 06:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765895277; x=1766500077; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=dfdC9zwoly3se4fqy2xxy3vdEF9ng9Mfmwel5Y1hgAA=; b=fFANVyGTLDIdI7RlxzyoCmzro7v+EbdFmecRtrrVj3NCBw47A8BPv94DnN9gedmUQ0 VryZX6/0kuUY+gjkOldKndGjuHz6g/9eExdg+FNApQl2asOg0FE0Gz0r0JiRx1klVNik 9OY8Qx1RR0DeiY/SwbYLcY+WDPSnGyHam2WuTXVOIlKctmPLCwfcZoFKjwPpa68Y9vEa VKhfN0+e0AiRxBixEgosbcVAzthJ6/X40V1RwJoYHWjJFwxjpLIOryLZ2foiAALSYZev LK+XR9W45Fa/7iQI2ePboa1fCNiuJhQyWdvhcx6/zDjHKMDs0MjvQ3w0DnMMmmYFvzeN YoPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765895277; x=1766500077; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dfdC9zwoly3se4fqy2xxy3vdEF9ng9Mfmwel5Y1hgAA=; b=Fe+eiV4fxA5U8BTfBfepC+XWXAjU7yJOJtLFU66JblA6K7eN7bVstiRNVaWHvrXFcP ETxs/OUDMltfjyBFM4D0U2lf66iJtj2hNXhiSiQ9o7x0cetlgbmaVwmyyIgLRYUdg+FF /w+FPBrL9R77nxuP5M9kzpvAYGonoTmJ0ATayDPiu4L+6Vv41X9cN8Zz4zg0U5HTuVp5 d7XFzMK0uXifnbuPY13ioOOLpJd1C1k6eDM6Rvai/vqq0tHqZDdGKwecldh6CYkddizr nzcvsAytioN606fPezyGgly5ckiBVwIYk67L1rUQh3VGz54UiU6O+cAkjQ7lXjHIZeJv ABmg== X-Forwarded-Encrypted: i=1; AJvYcCXiKm8DeXWXDs8WQkeEcamrWS9W+SN2LfWZ/b0oRaoF2VStgXWLe4YayP7TGpkIg+ZyE9FzOm89lPE/1aY=@vger.kernel.org X-Gm-Message-State: AOJu0YxWHha3tsZy5gJs5e8JfMeDceqhMzC67IbXfge+G84YSXIZ9hxH S56YLha4XmhM1GwC/rKjaImwTQtGuoKLuD2L4buJ++pk3nR3MCZTaHGByFubBVkn X-Gm-Gg: AY/fxX7/NDte52vUEN6LzPQ6PG7Cp6/WKMEz20nG18mrSB2nO9JaQ520W0Gmb2qkBiD d32g65Aqv1r1+03weS8NhMsHcP2yvQI99o1UWm/BrkQg2krOZyA0iHdH+kwNXs6QlF9JKjUgIZ2 aJ3br6UeLdGvy8kEZ6gBYxIxB+1XZJLoV5JeCVVaNf+G//P1oZjevYvQrZUPeWaDoZQa1pNBV8E oLjChb3vj2XqzD3YVd2aazooRA5/qt6pvFYsgerGS1iIJcWYLKInNFB35VCx4fnZ2W7RWcdyF66 Nb1gg1P9jk4pehybrenCdwlJAMcW7a/ahRTQBX6+5oOO/VE7kKbu/71LWspaZRFYmHrMbz/b0Xq SYa78wv405myLmFnSbL/dXjuZwVjS70FImaIa7KW628zvZ7g3d5agNQYH3uyQoD3OxIkb5EWNQt DiZ/nLJZ9RBUmBJe4dsT23 X-Google-Smtp-Source: AGHT+IFg02Hi0WbPNj8mzUVcXOn/4YdaH1RRdSY/tPIv17mjHuSRtc0P1tlO9ub9ILAZR6ig88y/cQ== X-Received: by 2002:a05:690e:1206:b0:63f:9979:2f9e with SMTP id 956f58d0204a3-645555cdb95mr12262586d50.17.1765895276401; Tue, 16 Dec 2025 06:27:56 -0800 (PST) Received: from localhost ([2a03:2880:25ff:6::]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-64477dc673asm7751945d50.25.2025.12.16.06.27.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Dec 2025 06:27:55 -0800 (PST) From: Joshua Hahn To: Andrew Morton Cc: Daniel Palmer , Brendan Jackman , Johannes Weiner , Michal Hocko , Suren Baghdasaryan , Vlastimil Babka , Zi Yan , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com Subject: [PATCH v3] mm/page_alloc: prevent reporting pcp->batch = 0 Date: Tue, 16 Dec 2025 06:27:53 -0800 Message-ID: <20251216142755.2857688-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" zone_batchsize returns the appropriate value that should be used for pcp->batch. If it finds a zone with less than 4096 pages or PAGE_SIZE > 1M, however, it leads to some incorrect math. In the case above, we will get an intermediary value of 1, which is then rounded down to the nearest power of two, and 1 is subtracted from it. Since 1 is already a power of two, we will get batch =3D 1-1 =3D 0: batch =3D rounddown_pow_of_two(batch + batch/2) - 1; A pcp->batch value of 0 is nonsensical, for MMU systems. If this were actually set, then functions like drain_zone_pages would become no-ops, since they would free 0 pages at a time. Of the two callers of zone_batchsize, the one that is actually used to set pcp->batch works around this by setting pcp->batch to the maximum of 1 and zone_batchsize. However, the other caller, zone_pcp_init, incorrectly prints out the batch size of the zone to be 0. This is probably rare in a typical zone, but the DMA zone can often have less than 4096 pages, which means it will print out "LIFO batch:0". Before: [ 0.001216] DMA zone: 3998 pages, LIFO batch:0 After: [ 0.001210] DMA zone: 3998 pages, LIFO batch:1 With all of this said, NOMMU differs in two ways. Semantically, it should report that pcp->batch is 0. At the same time, it can never really have a pcp->batch size of 0 since it will reach a deadlock in pcp freeing functions. For this reason, zone_batchsize should still report 0 for NOMMU, but zone_set_pageset_high_and_batch should still interpret it as 1, meaning we cannot get rid of max(1, zone_batchsize()) in zone_set_pageset_high_and_batch. Suggested-by: Daniel Palmer Signed-off-by: Joshua Hahn --- Reviewers' note: This patch was originally a part of the 6.19-rc1 pr, but Daniel Palmer kindly reported that this patch causes an issue on NOMMU systems [1]. Thank you, Daniel! I wasn't sure how to credit here since it was a report on an unmerged commit so I went with suggested-by. If this is problematic please let me know and I will change the tag.=20 [1] https://lore.kernel.org/all/CAFr9PX=3D_HaM3_xPtTiBn5Gw5-0xcRpawpJ02NStf= dr0khF2k7g@mail.gmail.com/ Reviewer's note (to Andrew): This replaces commit 2/2 of the series titled "mm/page_alloc: pcp->batch cleanups" [2]. I thought it might be best to just send out this patch and n= ot the first since the other one is already in the pull request (and seemingly without any issues). If you would like me to resubmit the series, please let me know and I will do that! [2] https://lore.kernel.org/all/20251009192933.3756712-3-joshua.hahnjy@gmai= l.com/ mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index f928d37eeb6a..95172f4610ff 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5888,7 +5888,7 @@ static int zone_batchsize(struct zone *zone) * and zone lock contention. */ batch =3D min(zone_managed_pages(zone) >> 12, SZ_256K / PAGE_SIZE); - if (batch < 1) + if (batch <=3D 1) batch =3D 1; =20 /* base-commit: e0669bdbba170f6c1a7bf5763f72df3f58a4945c --=20 2.47.3