From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-185.mta0.migadu.com (out-185.mta0.migadu.com [91.218.175.185]) (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 87A183546E6 for ; Thu, 11 Jun 2026 13:32:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.185 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781184740; cv=none; b=g4al20FbFV+uauUi9lOXN12HgIdgr9NxFmQwImtUmTbDiPztoeKLdkRsgDSQDG0RxEhYKsHAc6G5fX4FdlzxUDqCZANxRWbKvNiGVWjNf3eERydQtAFFVT57z3dDtmaOlCKKBCYT8BJU7RwpbOInqoR09b0Uf6I8gUmsur9YS7w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781184740; c=relaxed/simple; bh=cOQOHQpws2JyWXtcESwoyyuKhMWn+3gPeTraZnNOrVM=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=J+rLoqFsi3QDbeE7Oeetd+qa9/UD6DdidON7sO8NRmm4m64xcFUSi2XuGkUEEnKkRjVl09+ZrYzn+V/rxyiX/wDmgX+JHbT5o4DR42nt8KosNrcb8Kx/r+pE7iHyaQU3yEPQCE+jWOZNGYVg1hGTsE/rxLNhlpjZm+mZNhTswbc= 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=i5si0gMg; arc=none smtp.client-ip=91.218.175.185 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="i5si0gMg" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781184734; 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=OuV61uJXJ0l52LWb45Ax18tS2nrRIOXXxla2pXzq8v4=; b=i5si0gMgCTHy3hfsP5aiUh4vUDvjaZoA/rcYZvHfTKESJKjMj788WnYkJGHQ9UNUmbBstK 6kekJ9p9edxr+gmaynixI62jL+4AeN8b+UsnRur9f2utRd+BuKcwVRW00iKqyEtSZN7Ac5 LqoU+FUtYHxtPOI9alvyzZnY20odt+c= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 11 Jun 2026 13:32:04 +0000 Message-Id: Cc: "Brendan Jackman" , "Johannes Weiner" , "Zi Yan" , Subject: Re: [PATCH 1/1] mm: remove NODE_RECLAIM_xxx macros X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Brendan Jackman" To: "Petr Tesarik" , "Andrew Morton" , "David Hildenbrand" , "Lorenzo Stoakes" , "Liam R. Howlett" , "Vlastimil Babka" , "Mike Rapoport" , "Suren Baghdasaryan" , "Michal Hocko" , References: <20260611124501.1465806-1-ptesarik@suse.com> In-Reply-To: <20260611124501.1465806-1-ptesarik@suse.com> X-Migadu-Flow: FLOW_OUT On Thu Jun 11, 2026 at 12:45 PM UTC, Petr Tesarik wrote: > Change node_reclaim() to return a bool indicating whether any > pages have been reclaimed, because that's the only information > needed by the only caller, get_page_from_freelist(). > > Originally, I wanted to convert the preprocessor macros to an > enum, but I couldn't find any explicit use of NODE_RECLAIM_SOME > and NODE_RECLAIM_SUCCESS. That's because they are typecast from > a bool.=20 I'm slightly confused by the "typecast from a bool" thing - nr_reclaim returns nr_reclaimed and then node_reclaim()'s caller gets that value directly - is that what you're referring to? > This seemed a bit fragile,=20 .. Which, yeah, is awkward, thanks for fixing it. > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 3f3ff25e561ac..64f6b649eeac1 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -7786,9 +7786,9 @@ static unsigned long __node_reclaim(struct pglist_d= ata *pgdat, gfp_t gfp_mask, > return sc->nr_reclaimed; > } > =20 > -int node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned int= order) > +bool node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned in= t order) I really dislike returning bools with no obvious polarity. Personally I would keep NODE_RECLAIM_*, (optionally convert to an enum), move the comments to the definition of the NODE_RECLAIM_ thingies instead of get_page_from_freelist(), and fix node_reclaim() to return NODE_RECLAIM_{SUCCESS,SOME} expliticly. I realise this philosophy is not favourable to concision though, I won't die on that hill but could we at least get a comment on node_reclaim()'s defintion... > - ret =3D node_reclaim(zone->zone_pgdat, gfp_mask, order); > - switch (ret) { > - case NODE_RECLAIM_NOSCAN: > - /* did not scan */ > - continue; > - case NODE_RECLAIM_FULL: > - /* scanned but unreclaimable */ > + if (!node_reclaim(zone->zone_pgdat, gfp_mask, order)) > continue; > - default: > - /* did we reclaim enough */ > - if (zone_watermark_ok(zone, order, mark, > - ac->highest_zoneidx, alloc_flags)) > - goto try_this_zone; > =20 > + /* did we reclaim enough */ > + if (!zone_watermark_ok(zone, order, mark, > + ac->highest_zoneidx, alloc_flags)) > continue; > - } > } ... or keep the intermediate variable and do: bool reclaimed_some =3D node_reclaim(...): Since then the variable name at least tells you what you're looking at without needing to jump into the function implementation.