From nobody Thu Dec 18 23:23:19 2025 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) (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 E551B18A921 for ; Tue, 16 Dec 2025 14:48:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765896504; cv=none; b=iCZyWTZS4FHQNpuYMlUL9PwszHuQsQmM7cQqfb6uZCdLvyiIW2Ml3Gmu/SHi9q5Ch2sCVLT988MSTePl+UXnTjCdsZryuzlOu0NT33e40+QuA4N0FN5GcP5zWexrZaaWLy8TMnBKdfUWX7rMPqj1JoWDBvxJAyASkzMZxa4WRP4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765896504; c=relaxed/simple; bh=w6O5IOCXp8faX/KtTsh8D9TNeV+irIdmB12rAoiAK98=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Hhw2eSuOqKUOPvQ2oq9MHgdK50GlrZYbYHpTBbf9PIP0fwvRhG8h5z0tzTYUJcNoxD5WKIOSwETgGVIdB1UlSwAusbdREWKMMW3wrnPrdJiYZKRyFRzCGnbGyTiW5/fNSdGM0K3JlrwsAItlFBZ0e1X1j9N/EU9RyB4MvKUP0s4= 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=ei56pV2m; arc=none smtp.client-ip=209.85.128.169 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="ei56pV2m" Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-78c4d112cd8so44380977b3.2 for ; Tue, 16 Dec 2025 06:48:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765896494; x=1766501294; 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=9D800N3llW1Kz/jDDU7ypPKI470/5xuGDSE+ejd9MKQ=; b=ei56pV2ml0O0s3+jZ/m6ks6x7yLRwk9FTxiQW5rGJgAak878p+AhXXQ3Pa1Hi81B5j qchQ911Qztwj6vfhW+ZWGw9/uCzIZK/wxhcTFXGUbjjo+sq5eVTN4IqmpbhEm1oVyHq7 67JXGAlYm5XcrRbixJx4DRDcJlxfDlfIRjPuFYQxiQ46Ca7Ug/b/sJy3uBMxaQLmUvVT lLD7wiw7uVAxCfwl/3bZhMkOtjSrVOAUz+TT4x4k4xnd2+zUJJnYzrV3bV2rQQmwua8Y c1GDRBlvYxCuiEEJXBzHDuObOKt84+eoGiDakZgK1KcXPAu+Tp+1loJmCrOERyJRtVTd LzRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765896494; x=1766501294; 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=9D800N3llW1Kz/jDDU7ypPKI470/5xuGDSE+ejd9MKQ=; b=D+Va/gS7/eJ0l/egCRTLjFJzs1lXlkbGXfP37P6Rt1AU+xn51+3mrDCztsOrrhlvun 5vxehVTMdC/cmchA2YnGexcqnfakup7YeumlBsgIiXZclD4s+ZkuSwZSWU51SDI4tfq5 eEFjGCFtsOW6yxyRvASgHEZBCFYEec2xxNhkdt83BDQHOU7Re60/f48giLUFf8ouOU0r NRJBzuBjzWW7uNJU5KYe0USFpLoiAkMTmt0Ah0LRFXcdhrmxAHUDcJGpbgpwzKcX+t4U o02W611cdfYk168v2YXfU4hjJFF95odwjZ3PLCp05rWZqFQ98Yi0WE8rfCqC1ZG8TO4e rMzg== X-Forwarded-Encrypted: i=1; AJvYcCUdDcKjdIg9ukCfPBcqK7oTx4EmPZOz1DM6qewDl+vT+/OgwnmoQ92f3YtYdibqaTkvyiNSI1ArvzRNJv0=@vger.kernel.org X-Gm-Message-State: AOJu0YyPHTcw/F2Dyu4/+7gCy85+11Fup0oqb+XNxdd9Uif426F1LiKw qd/TBXF/usQtDs5QXmv38NxHNQFnvZfspxYc+hi13tkeStfggLrVwTjO X-Gm-Gg: AY/fxX40PSWMkihgYA9oAMD8gn7hLeVrashe5KlJ97sAXbdx3fHiWREAaxciPwOhksd I9JD5Cgv0CwetuT8HIxQuViCLxqPRC+fCQkNe6o0ow/DT4BGJZD/TDLpdC1yikOoT1Xy49KfdXD zYUBJWXxGV9vkPnzrNieD555qgFQDCuKHrGRWw25xm839I2NCX53zs/+SNXBLmiroCs4uN0z80G rXUTfigDgHrPRM8n05qR7khBN/HN4aePmj0a3u5JmE3uOfp2VUxM6r9pT9ufLjFGJIR/38lAhTU b0VzQh3mNrkKx8gYwktAKkIftgMnGJvRkQBnL/aBQ4qNun5jeU+P87J3TNEsnwVyYes8Aq6S+fC Cc/T7sgCv37vkXo+xG8CHAVUlRMYPG/0BuMemnyNsY+0VPIkX9m556l7Vt8UdwfjddkMLjmNAJR FNuGDilQqTTBXCxSKhqJ2T X-Google-Smtp-Source: AGHT+IHtppcQCCTw+R6UF6XppihsZXaZ6mX9Bz4khFIM5iZdR1k6bH3QC/ci6nE1FOQaT2+D2MQtkw== X-Received: by 2002:a05:690c:4988:b0:787:ed2a:79df with SMTP id 00721157ae682-78e66caa9afmr252323927b3.10.1765896493956; Tue, 16 Dec 2025 06:48:13 -0800 (PST) Received: from localhost ([2a03:2880:25ff:6::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78e749e550csm39513627b3.29.2025.12.16.06.48.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Dec 2025 06:48:13 -0800 (PST) From: Joshua Hahn To: Andrew Morton Cc: Daniel Palmer , Matthew Wilcox , 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 v4] mm/page_alloc: prevent reporting pcp->batch = 0 Date: Tue, 16 Dec 2025 06:48:11 -0800 Message-ID: <20251216144813.3016985-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. [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 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index f928d37eeb6a..a7448840c5fd 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5888,8 +5888,8 @@ 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) - batch =3D 1; + if (batch <=3D 1) + return 1; =20 /* * Clamp the batch to a 2^n - 1 value. Having a power base-commit: 65dbdbbd25f928b8a56d9a27d97a6c668ce1ef08 --=20 2.47.3