From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) (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 9A30C2248A4 for ; Wed, 17 Dec 2025 05:18:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765948688; cv=none; b=rLSxnNmXZOgkYzmY3BDf3n0j9R+oUjsg0KKRAOSlvJc3+zPSsZ52WqjOvWsZwlXRkhRiekUlNx5VD7mLZGVbHKVhqx2sTMyrm8ifFzTK+kFlcLhvbNMc22ujOSyZ8QRDM02hQZ6mMUKdKOevNSmcZP6PL7hhcP90XW5LUwey+I0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765948688; c=relaxed/simple; bh=+9HrHRwDue9dWkobPgR6swMrVe7gnwZyISsBi0VJDqc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DeAShqEWy/7hZwsG5W8mzM+Xo9O7RExVd13oA4IBx+wgaWzK4GCwait53Wh8mAgs4k6WCLZBEhOdBjOLJHBCWB3xEPDaaA1QztrDQ0xuyLyL6+K1lhJlOqj4I4Nxgdg3s9h7DEHNikSQfS6HGDhuO6WoXM03Gki/zP/RwQ98zo0= 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=GIPYtoGf; arc=none smtp.client-ip=209.85.128.175 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="GIPYtoGf" Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-787eb2d8663so2705227b3.0 for ; Tue, 16 Dec 2025 21:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765948685; x=1766553485; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=2anOrP0xVCL+Jbr+Dqygt+dHRR+qw2sgfwGJ1BYaHxw=; b=GIPYtoGfiajP9hWlODLeakTrYF8eUJqlR06F4Gz1Lg/OOhHcI3X1O5YxySPNDs2975 McdkkfzkTnIewWX3CS0wHvOTx/2cJo4pLg5fU8Gq2ZkIDrVGfubyyD8dq2nVN6FeINkq UODs243azdZoCsdtsjh9j+Kd9f0wWtk0BGgunv/pFIsoqtUbTAuJzFkGuiQIo2GUXk6w mLO6bChF6fxAO3kG0K/Y53sz6Zs+He+HZB6ml2P9Tl7XznIZexGZpLuKl/gR3JIbLPu6 ZpCvnVYHcs7WKc0KeB/4w3pdlfd/93AjEstM72TiBUw0ZH4Dpjeyns+EbvZFmTOCdLo7 dO4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765948685; x=1766553485; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=2anOrP0xVCL+Jbr+Dqygt+dHRR+qw2sgfwGJ1BYaHxw=; b=rbAtNWa2hJKHaid87clVrcL7Tno/NoCokeEVpzglF7hqrc1xYn+LkxlbCgOd6E2y1j xbwxkhDd6W1GnYqxfs3FrSPhSe5zPzEW7lNRKylKpVVa8pcDAruGPKp4eTJ0AmNyo8sv iH/p5ujchMy54ec7OW69GHCSxGWcskehRAuf1U26VvRNM+nLwhYNqvS65K0ZJt9/hFUB ESeEJ14HNrx4nRvkJWXdoi26TAIP9hFNoM2PlRgtMu9znK4sXy2yoS5PrzBt0Ohvor8n qoaF8QLBQcz9xkFq+U/M6hSNsQ7LHJi2QpJ8Rhh61qCwROQo2yzM1faiqsFHmmmOxuCB liAg== X-Forwarded-Encrypted: i=1; AJvYcCWzqPu107z6hMtULJUlObZ2eXuPBXnKkuBidZ7Qz8EI/Xqf92qd1Y8BOpCwm0LaHtwxi+yxZzVz/IRmLAM=@vger.kernel.org X-Gm-Message-State: AOJu0YwKOKBxUhAQ62TRmPAQyvjepgFek0KGHzIDoLtAZF/lnrj8w8Pu WWW7jERDFGqc+N9aRLGayjgw36ev0uFQPrGtFH2yR8Y10haXshpY/azl X-Gm-Gg: AY/fxX6WvWDwxdN7NZq80wh09IX4mlbPoM4mPebRCB2jT2q9JN7oorzw3PQRMym4nZy Nu6pQV2VK/MU/Z4mKSSZQETNWYI8FkDSuCVTOxJ+/NmuWJUAUykiJf0oryFYKile+3O01Ffm++o eSTjeEElrffhh5bOQ/821PUqOyPlqmo1zwTTzegZvJQDCb79cZtplZSjnVB4xsL+uhKjZa/Qt1p 8UEdO9/Ju4LnY1qgEyp0b9gsbOKKFc2GrKzpSrsKLQ45UUjBT4eHtdhhHGJY2RjZPEapEi5I412 TCNmamaf0juKxu3vUjXzJhDM/W47GaqlPAJyLIHhTdgZreBbJeF+AQbNOOWUU/DiH3aC4faiFMu bmTwqkzrKkWK0RlRPO3ebpaKFWmekSP/KusN2ll4fskk3U1pxfaDwqACzSVONXkXA908YiLVlGN jdyUktOTtnEL7tsdcTOarj X-Google-Smtp-Source: AGHT+IFTh5UrsnE3aPhMBKEHXPd4JmUA3m4FDvKhZSc0MEfZN0xTDRHHnB/MD9iVwyuFUiBF7ZAz7Q== X-Received: by 2002:a05:690c:61c3:b0:78c:2ad9:b541 with SMTP id 00721157ae682-78e671a1ad6mr140386417b3.31.1765948685220; Tue, 16 Dec 2025 21:18:05 -0800 (PST) Received: from localhost ([2a03:2880:25ff:8::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78e749e5ae2sm46668267b3.27.2025.12.16.21.18.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Dec 2025 21:18:04 -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: Re: [PATCH v4] mm/page_alloc: prevent reporting pcp->batch = 0 Date: Tue, 16 Dec 2025 21:18:02 -0800 Message-ID: <20251217051802.86144-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20251216102205.1d008d1432446956b079bfff@linux-foundation.org> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 16 Dec 2025 10:22:05 -0800 Andrew Morton wrote: > On Tue, 16 Dec 2025 06:48:11 -0800 Joshua Hahn wrote: > > > 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 = 1-1 = 0: > > > > batch = 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=_HaM3_xPtTiBn5Gw5-0xcRpawpJ02NStfdr0khF2k7g@mail.gmail.com/ > > > > Reviewer's note (to Andrew): > > > > This replaces commit 2/2 of the series titled "mm/page_alloc: pcp->batch > > cleanups" [2]. > > That series is in mainline. 2783088ef24e ("mm/page_alloc: prevent > reporting pcp->batch = 0"). Hello Andrew, Sorry again, this mix-up was also avoidable. I'll be more careful in the future. > > --- 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 = min(zone_managed_pages(zone) >> 12, SZ_256K / PAGE_SIZE); > > - if (batch < 1) > > - batch = 1; > > + if (batch <= 1) > > + return 1; > > > > /* > > * Clamp the batch to a 2^n - 1 value. Having a power > > > > So this doesn't work. Please send along a fix for current -linus and include > > Fixes: 2783088ef24e ("mm/page_alloc: prevent reporting pcp->batch = 0") > > and Reported-by:Daniel and the appropriate Closes: > > Thanks. Will do, thank you for your patience. I hope you have a great day! Joshua