From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) (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 9BAC41DF27D for ; Fri, 12 Jun 2026 15:10:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781277033; cv=none; b=rixXjr3PpxOMZAds0XXA09gDwY4NrtN9AZXNdmcCuMHGO76jpiA3AtGfN9ss6lWtTJwdNIZa9tqmhjG4HdzNv9EMvewOHW+Rx8T0wOuYbqkZ4pKciMNU6uIlJ86tOhCTletGccfHqIHhCzN3TpLAyR0U1DgweDkWQKpGT9ZRO8I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781277033; c=relaxed/simple; bh=vETadUdFWPIZSmkn3s6a5yscPtes6vXCqdVovqBOYkc=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=Ug7R57T7aqsS6JY2k7CT0heekz7v3lRSTcoeqSF2SdpagXsIGhZzXy6kiRPdW/8+tnluzcdh4enESgD7NIVGBZy5Bf/YxRl5KRqgX4w15FVU+yEH0i728aZjeshjZkhth2HqLqbgmGYzDwubZPY2wxy+Sysygn9/XmDfPWjM9hc= 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=ewMEzuCT; arc=none smtp.client-ip=95.215.58.187 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="ewMEzuCT" 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=1781277029; 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=51hgMgSJtrgvkUbKDUHJEqr1K8Hb4cZzs3NFg+YtaPY=; b=ewMEzuCTQHXqNIJMFgxGOGXsRO4rKRytksObryGm8pu7kyyHR4jv4RY6gDThZnQ+gSsVua 69LwC1DtkhUGRaQqjRL8Szgqv1b+RP3/PlH0NfMzVoiMz0za2xJd2TtrVDD/o2bEucXSK0 TQNbmyEqOAGyawnDJWQ/XBLZey8Rr5M= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 12 Jun 2026 15:10:18 +0000 Message-Id: Cc: "Petr Tesarik" , "Andrew Morton" , "David Hildenbrand" , "Lorenzo Stoakes" , "Liam R. Howlett" , "Vlastimil Babka" , "Mike Rapoport" , "Suren Baghdasaryan" , "Michal Hocko" , , "Brendan Jackman" , "Johannes Weiner" , Subject: Re: [PATCH v2 1/1] mm: reduce NODE_RECLAIM_xxx and change to enum X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Brendan Jackman" To: "Zi Yan" , "Brendan Jackman" References: <20260612085052.59291-1-ptesarik@suse.com> <20260612133155.71958e80@mordecai> <34223C0D-B52D-41D4-AACC-943A4BEB3472@nvidia.com> In-Reply-To: <34223C0D-B52D-41D4-AACC-943A4BEB3472@nvidia.com> X-Migadu-Flow: FLOW_OUT On Fri Jun 12, 2026 at 3:01 PM UTC, Zi Yan wrote: > On 12 Jun 2026, at 10:28, Brendan Jackman wrote: > >> On Fri Jun 12, 2026 at 11:31 AM UTC, Petr Tesarik wrote: >>>>> >>>>> - NODE_RECLAIM_NOSCAN -> NODE_RECLAIM_NONE >>>>> - NODE_RECLAIM_FULL -> NODE_RECLAIM_NONE >>>>> - NODE_RECLAIM_SOME -> NODE_RECLAIM_SUCCESS >>>>> - NODE_RECLAIM_SUCCESS -> NODE_RECLAIM_SUCCESS >> >>>>> --- a/mm/internal.h >>>>> +++ b/mm/internal.h >>>>> @@ -1373,23 +1373,24 @@ static inline void mminit_verify_zonelist(voi= d) >>>>> } >>>>> #endif /* CONFIG_DEBUG_MEMORY_INIT */ >>>>> >>>>> -#define NODE_RECLAIM_NOSCAN -2 >>>>> -#define NODE_RECLAIM_FULL -1 >>>>> -#define NODE_RECLAIM_SOME 0 >>>>> -#define NODE_RECLAIM_SUCCESS 1 >>>>> +enum node_reclaim { >>>>> + NODE_RECLAIM_NONE, >>>>> + NODE_RECLAIM_SUCCESS, >>>>> +}; >> >>>>> - ret =3D __node_reclaim(pgdat, gfp_mask, nr_pages, &sc) >=3D nr_page= s; >>>>> + nr_reclaimed =3D __node_reclaim(pgdat, gfp_mask, nr_pages, &sc); >>>>> clear_bit_unlock(PGDAT_RECLAIM_LOCKED, &pgdat->flags); >>>>> >>>>> - if (ret) >>>>> + if (nr_reclaimed >=3D nr_pages) >>>>> count_vm_event(PGSCAN_ZONE_RECLAIM_SUCCESS); >>>>> else >>>>> count_vm_event(PGSCAN_ZONE_RECLAIM_FAILED); >>>>> >>>>> - return ret; >>>>> + return NODE_RECLAIM_SUCCESS; >>>> >>>> Should that be returning NODE_RECLAIM_NONE when !ret? >>> >>> No. That's the thing. Before my patch, the return value here was either >>> NODE_RECLAIM_SUCCESS (when at least nr_pages were reclaimed), or >>> NODE_RECLAIM_SOME (if less than nr_pages were reclaimed), but the calle= r >>> makes no distinction, handling both cases in the default label of a >>> switch statement. >> >> Agh! Sorry. It's good that you are cleaning this up :D >> >> So in that case my question is: is it intended that we call >> zone_watermark_ok() in the case that we reclaimed 0 pages? > > It seems to me that zone_watermark_ok() here is trying to > confirm the number of reclaimed pages is enough for the > allocation, although the return value of __node_reclaim() > might be able to tell the same thing like you suggested. > But nr_reclaimed >=3D nr_pages might not be equivalent > to zone_watermark_ok(). Yeah but in the more specific case of nr_reclaimed =3D=3D 0, would it make sense to assume !zone_watermark_ok()? It doesn't seem that important in terms of behaviour but I think it would be a clarity win.