From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f48.google.com (mail-yx1-f48.google.com [74.125.224.48]) (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 43F3C1E1E0B for ; Thu, 11 Dec 2025 22:59:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765493991; cv=none; b=uNTLvBdCktjPkgLmQTfNBr4cICGwjNDy+w2emiQsraQUH0WSa3dMqgVQuHaAn57E+TCnNHkynbtbNkN4NwxOqki0PZAy1diqOu6uKuC3+a/mnlLNuCa397MR+ETxb5PmwcT9AlhRAZoUY4YbdF3aOOsEbfmtDbqLAUsWXu6/Dgs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765493991; c=relaxed/simple; bh=H0Xz/irq7FmyBN3PvoRZF5cfAE/b4bJI77DZGILjm40=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IluOIJmSTaB3MXdALj5iFtNUpLL/C3mermcoFgr7xU9RtCuxD2VJ+qJY7rsteuZSgvcODfANPVg/1yyI3i8/DAO9MXlua+z1RFyLuh58+KjCjLy+0MNDDrNx+TvU/R2MkGNBYmetecvy+Mm9hHYxytH190ymn2JU6E3QzmE4Pkg= 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=Hn399YuG; arc=none smtp.client-ip=74.125.224.48 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="Hn399YuG" Received: by mail-yx1-f48.google.com with SMTP id 956f58d0204a3-64472ea7d18so570395d50.2 for ; Thu, 11 Dec 2025 14:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765493989; x=1766098789; 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=SlR5dyPRStLA8uVUCn+GxTt6FuED+oaJ+jr0XhGSKT8=; b=Hn399YuGaaCCDN37LI9i2MU/3WqFtj5VeDb3ABSAx/pBRQj605ClEjwvxmhHBTvmiY Vq3/Au+yWAkzmfb6wqa06QVYip5S0YZX7WWPdsVioE2vKnmKQxV4lPgrQbvojWVLtKqD Rcn4tWnR/ZCHgrEUCoXBeRdxMuCoBRK1rGC/ed3MtQwsD93sH6z7PmCmrrUl1Gb7Nizg NR3s0zlkc85m6F1G03yvoMAva2zKx/o7jxLg+E5LvMBLVwH1JLpkczT1+cFjIPTW+n0R /5bAqslCQk6q8WF50Ri5ylsyncGZRPD88sXP+JzTQs7HdMxVyOdX1KW9PeftdjM7gB3j Ya5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765493989; x=1766098789; 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=SlR5dyPRStLA8uVUCn+GxTt6FuED+oaJ+jr0XhGSKT8=; b=BlPEhg3ONt+/Qgn5giAtg7RmApwlBWKH8Wkeg/gi4JOhnt+pkuwcB+hHVePCHExPG8 DSEa+t2+EfPdNUVp7FjHg8N45iKsWqpSSg0J1YrJeeVK3OBQawPvzshV2SpNBDowKDnZ lPa1Kn/d5DLwHdVmVnCQPV6A4bouqdCb8mFhpfEvKt5wo6MDZS3t5K67hz0kkKBKrSzZ MLh5ahL24LyvAnLxNAhdRDmisNfI6RzV4F0nHnqI6Au16KeQMt+2C6/yQ5r52UaYK4B0 CX9pPnd19t6HqKePo9BAuwrAYDIKt2wYgRoJCHlLpA22Rl4t0xtaPaEPA3d9XRGzdFxL 36PA== X-Forwarded-Encrypted: i=1; AJvYcCWUYuB0hLMKOy3obBUypA2c6Zf0hM+UbyVP3KuHOv7zfjkpQEQpYb4YGt3NHGs5e92+VKocUjH1gyxdmaY=@vger.kernel.org X-Gm-Message-State: AOJu0YwlMrP8t7ijID6F2Jc7QbSs24eDiyMoFxftqutPbnuJuNMpghQ2 yX+dkBG9x7TQVWvjiVkiSNwJQykiMoU+SM8WGAu+U3TWyjgThtjlNaUoFBd7LQ== X-Gm-Gg: AY/fxX4ylDYsCBEw3uwqOlVV2gMz2lp5C/EYiH92DtfLLfizDYABQyZz0sasvvYUES4 RwghtMaTD6PWuDPA/5kwjmFpTO+Pm4BVMoKzVS6PtxHu8ds3XGayuO0r50vmvB9DnTF5pH7tgRS CYoBWOXndP5R8wHFZYBVo/31Kz3jcEYdX//E2VOkXvkxH2NWQWCflr7bKJWWYIdpe083qhZ+35X gJCnr38Ge155ijTIbSQBbxOYoODBcwO56xmlvMaCT4dMCCuVazayYpaq9Vh1fJbyPRGSGXYeT3X ZRSGwdcUf1ecf+Bo7m7tN7FN2dkHBs3K9KdFuMv/opqdL2warJh+1gtLLuxFHVcBchRcCLbNhx2 /0XtvBerq6Y42u/bkRn4313Ujx4NHv3XwAf04qYF9i6n/YsUtAXUdMCtuiV/jcsEYL1ZW9nx/N2 Nhvmvdw/9rFaegc8kciRJu X-Google-Smtp-Source: AGHT+IFw2vGNNjjj3/jRl2oZ08zme4Jm23Xg+NsVTpZN7KhFXaP5tMl5DMXggaKmd8kLUyaK9fttPA== X-Received: by 2002:a05:690e:2441:b0:644:4f94:c530 with SMTP id 956f58d0204a3-6446eab09a1mr5210641d50.39.1765493989052; Thu, 11 Dec 2025 14:59:49 -0800 (PST) Received: from localhost ([2a03:2880:25ff:4::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78d69c60507sm13907097b3.17.2025.12.11.14.59.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Dec 2025 14:59:48 -0800 (PST) From: Joshua Hahn To: Daniel Palmer Cc: Andrew Morton , Linus Torvalds , linux-mm@kvack.org, linux-kernel@vger.kernel.org, mm-commits@vger.kernel.org Subject: Re: [GIT PULL] MM updates for 6.19-rc1 Date: Thu, 11 Dec 2025 14:59:46 -0800 Message-ID: <20251211225947.822866-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: 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 Thu, 11 Dec 2025 20:12:18 +0900 Daniel Palmer wrote: > Hi Andrew, > > On Thu, 4 Dec 2025 at 14:29, Andrew Morton wrote: > > mm/page_alloc: prevent reporting pcp->batch = 0 > > I think, maybe, the following part of this patch broke nommu. > > - new_batch = max(1, zone_batchsize(zone)); > + new_batch = zone_batchsize(zone); > > Before this change on nommu zone_batchsize() returns 0 but the max() > changes it to 1. Now it'll stay as 0 and anywhere that depends on it > not being 0 won't work? Hi Daniel, Thank you for taking a look at this and finding that this was the source of the deadlock. I took a look, it's definitely an issue. The problem is that the patch gets rid of the max(1, zone_batchsize()) and handles the MMU case by ensuring zone_batchsize never returns a value less than 1, but the NOMMU case always returns 0. I think your solution below works. I've also come up with a simler workaround which doesn't change drain_pages_zone: diff --git a/mm/page_alloc.c b/mm/page_alloc.c index d0f026ec10b6..9d638697cec8 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5919,7 +5919,7 @@ static int zone_batchsize(struct zone *zone) * recycled, this leads to the once large chunks of space being * fragmented and becoming unavailable for high-order allocations. */ - return 0; + return 1; #endif } Would this be enough? Then we don't have to worry about handling zero values from the callsites for NOMMU machines as well. But this has the opposite problem that I was initially trying to fix, which is that NOMMU machines will now report a batchsize of 1 in zone_pcp_init and print it out to dmesg, which may be confusing for NOMMU users who expect there to be no batchsize. So it totally makes sense for me to drop my original patch completely as well. I'm not a NOMMU user so I am hoping to receive some feedback from folks who do who can chime in on which approach is better. > I'm seeing a deadlock on nommu: > > https://lore.kernel.org/lkml/20251211102607.2538595-1-daniel@thingy.jp/ I would also like to take this opportunity to ask any NOMMU experts out there about the apparent disagreement between the comment in zone_batchsize under the NOMMU case, which suggests that NOMMU is harmed by batched freeing: /* The deferral and batching of frees should be suppressed under NOMMU * conditions. And returns 0 here which makes sense, only to artificially set it to 1 via the max() later on and still do batching anyways by << CONFIG_PCP_BATCH_SCALE_MAX. Thank you Daniel again for helping root cause this. Hopefully this fix works to fix the deadlock you mentioned! Have a great day : -) Joshua