From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 DBE98201113 for ; Sun, 4 Jan 2026 09:04:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767517465; cv=none; b=SZM2WDv5E3fQ0IyhV/MHNSeq1Pv2L+yo9VNVd4buw8qP94ppoWx1bO9YenYlfVbfpytui3IdRMTnvil706seJDoR1amilYaaB0bRDVJlsy0oszmnzxkvrdD0qe+KepFzAM321YKvkwVcsHleAxun/3PloGD9ZXV2q4IJGBYYKvY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767517465; c=relaxed/simple; bh=QSOiATV59Jt7zF0mcNusY/T1zTDz582l3BXZAoUYnUk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ljW7nNx0wgkjoXxuHQu+zw8o83eoJU37fB5SeZthgkJ1E+16LYHQimewBEMu1FFYxO6WYZM3jm2SFvbAPnlUWx9FIiqcznP/jZast1YDsaZaPuE6xTW/zLZD+DdBk0A59/pwxo0m+wrcr8Lp4srKzE24rPU4K+KtjVh2TgGSdQ8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=phjW9tbY; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="phjW9tbY" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-29f02651fccso120995ad.0 for ; Sun, 04 Jan 2026 01:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1767517463; x=1768122263; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=QSOiATV59Jt7zF0mcNusY/T1zTDz582l3BXZAoUYnUk=; b=phjW9tbYadSKf1Lzs4m08kwD+zVofwZCBt8+dMH8BBXm0OpSMCJ4eCKfBbodS+M62w 0IblGitRNFhqPcDy5Fa7ULOttD11JUa69k5haDBPjt1fjk9Afh3F4MIoye5D5wD3+Q1G flyK6RiGJ8bUwMxQoUIOHyCNeW/Qafo/KFvhD/v61OCUnUqgDbdHrbWxFC7nLT2SL2J0 vIaDo4Ixm6fBEeO7xJSoCSFOUAavFMsADC/eUr4fUgPguRjGOQXXRIKzGlcgOi/MnDHG 8G4TnJLlPxnOM/TB6ygSTZjDEsxHvt799qbTS+EiXTVaemAoRF6xvd2E8ivtTvYEFW4e 2L3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767517463; x=1768122263; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QSOiATV59Jt7zF0mcNusY/T1zTDz582l3BXZAoUYnUk=; b=adtU3uBWbTRGUsWEhlfPSQy52GDcPPMn5fWaSppTwmcFacBjTmTqqT2qTqcfdPbYNH epJe4KaUpLXPBVsDsb1BO4koyrn0aYaWzgaTL6XYbWj3oBD/wk8KhEG0TR/P2w/fYqYo nkyFskbd3naWhjX7KFPCKwVTcKSaqZ37isoAMnSGzoKpXm4EFCk7XU35rM38GqHKZsAu 0W4dswjZu0hzeAzjNKbnuIf//yRVLOBeSAHZIpZKIv/psJpmejIteKO8IZhJWkbYmzia bIvALzLuv/njZpAfPj6eAuljIzaZLIQ0isSKtVQF9orfzQeQ1MbXuvsC76+JBA5X9eLn abXQ== X-Forwarded-Encrypted: i=1; AJvYcCXyubhC65X2nYTPkPtqf7E3Mm8IisL4teSBf731q05ToNl0h+0Jdsb/Fvag3wfEAzwyHTTUkFTCLMhVGGM=@vger.kernel.org X-Gm-Message-State: AOJu0Yw7tycuSQJlzlWPnZ4s3LbciOi23XKEDPIdTgjpaqIqGiR0Knrx kZEU86qIhPyi1QBLZsgmm0BFYyTHIUg5FCuJ2L+4uQodPA5BhM1GdyXNscf9/1zS6g== X-Gm-Gg: AY/fxX5iGMYWZaoqAU49sMRLw2baAUgiy/i0eFsvcN16ZX2e3whx49sbiaWIlA5cGBs scu/OChC9CUCzFGL2yPGbbyMai+1XBWH9bQpDU4YFzrMj3zPRiyiImqk3s0Rn7Sp8Ro6Dz+oTRE VPFgCDCYmBhYiXYDw4qpsVw9duoUvVFByzyAiDjlp4B1eqnJY1NNvdwhBBotw/RaEHWwNr8DoPN XYzBCbDWeVmE6G9+Hphi1TGPfBA4Fb47SJK67MCqbCNVi0HA0i973VmjxV2KOeMXf4yaS7Adgvs 9QexKO/LzvDUOD2Ly2QNBC8LSND+7GQudqC+gPi/a9KCA/joV+f5g0ynysswaJwRyQTUkzy0BGS OoPF8ipp5zLv5ZEcHz2PDspdGmFnv3oaPXKiGKbSHVnAx27sJRXw0+ptlJ1gzCDHROwnScE6xin gMlTn5C+lNnixJjC6sQJGET6Pa4gjvttdQg7fBl8KVcANBTFDII1xqQ4RmDSRzbnY= X-Google-Smtp-Source: AGHT+IF2f+qqRGbSWLY+axONWjGzW67AvjyMri7/vyDsrV41RpaLChtAfH7ihOiJuNWMSfi+MREU5Q== X-Received: by 2002:a17:902:ebc4:b0:295:1351:f63e with SMTP id d9443c01a7336-2a3c1c1615dmr1696435ad.10.1767517462607; Sun, 04 Jan 2026 01:04:22 -0800 (PST) Received: from google.com (248.132.125.34.bc.googleusercontent.com. [34.125.132.248]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a2f3d5dea1sm411421835ad.81.2026.01.04.01.04.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Jan 2026 01:04:22 -0800 (PST) Date: Sun, 4 Jan 2026 09:04:16 +0000 From: Bing Jiao To: Waiman Long Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, gourry@gourry.net, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, tj@kernel.org, mkoutny@suse.com, david@kernel.org, zhengqi.arch@bytedance.com, lorenzo.stoakes@oracle.com, axelrasmussen@google.com, chenridong@huaweicloud.com, yuanchu@google.com, weixugc@google.com, cgroups@vger.kernel.org Subject: Re: [PATCH v3] mm/vmscan: fix demotion targets checks in reclaim/demotion Message-ID: References: <20251221233635.3761887-1-bingjiao@google.com> <20251223212032.665731-1-bingjiao@google.com> <84ed9b5d-41d5-44a1-a1ad-2b3de8b50a50@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84ed9b5d-41d5-44a1-a1ad-2b3de8b50a50@redhat.com> On Fri, Dec 26, 2025 at 03:24:29PM -0500, Waiman Long wrote: > The nodemask_t type can be large depending on the setting of > CONFIG_NODES_SHIFT. Passing a large data structure on stack may not be a > good idea. You can return a pointer to nodemask_t instead. In that case, you > will have a add a "const" qualifier to the return type to make sure that the > node mask won't get accidentally modified. Alternatively, you can pass a > nodemask_t pointer as an output parameter and copy out the nodemask_t data. > > The name "cpuset_node_get_allowed" doesn't fit the cpuset naming convention. > There is a "cpuset_mems_allowed(struct task_struct *)" to return > "mems_allowed" of a task. This new helper is for returning the mems_allowed > defined in the cpuset. Perhaps we could just use > "cpuset_nodes_allowed(struct cgroup *)". > > Cheers, > Longman Thank you for the explanation and suggestion. I have updated v4, which updates the functions to filter out nodes rather than returning mems_allowed. In v3, the caller need to declare a temp nodemask_t to store mems_allowed and then intersect with lower-tier nodemask, which is unnecessarily increase the stack size. The function name is updated as "cpuset_nodes_filter_allowed". Do you think it is still better to use "cpuset_nodes_allowed" when doing the filtering thing? Thanks, Bing