From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) (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 D7BB629AB00 for ; Tue, 17 Feb 2026 18:52:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.66 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771354374; cv=none; b=h9mMdgtZUoIG5Zr6E75JDb5WbngiODdsihKiGdZXQ8NkIXMTkqIGCILoyY4jxAV8H8Y4+MKCiCf0epAMd0zGgpKVbuWJuZThW7tw8A3NU4F92cKs2TzXKgpgMXh4aKa91nnvxs+D7bPLO5RKFWWaE81Tzua2RfMr2aiISraB99s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771354374; c=relaxed/simple; bh=3ehpeb06kDgzJNWm4laQeCVtUuswr0jIzd35eu4fzxg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Uq+abkmjeHwrjCyJkO2O8mVSsoBb8MiBO/PZtfD2HnpeP7wLxx+ZDDFCYbSTuWxWOXme0htsZL3L48wsCipn310IeQMnISyf1baH79WZFhpJX8pErysvktFLOItsfjwWJYFP9eypLxt/qVXSkMg9AzLgzJdyYtkxrFMyrn+jCVE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=USP80Ryk; arc=none smtp.client-ip=209.85.221.66 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="USP80Ryk" Received: by mail-wr1-f66.google.com with SMTP id ffacd0b85a97d-4362507f396so4336314f8f.0 for ; Tue, 17 Feb 2026 10:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771354371; x=1771959171; 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=x46hiGoEyZZRfdFs36nFSz1+AdsW3p14nQ3Wm2zf6Qc=; b=USP80RykKT51B8nu0jWR04pW5k2RSVjQkV88pDPHd/3jSU6BT04hV1ht8fv9vvVB9t AgBv+rLoQPnKLD9ha6ob4u71s9BR1HSG9QJShr8JewP2P4VPKAqBJ4TX79pwguD9IU5o /d2z8m1y7EpEIIQRoy2hIbtdFKJP740x+7gTpZTp4lXPU1NWI/OgKu3LqcLsT32BAKLr Q7/u62DwaxJiMcFDPheitedzi0r9VkrRczSIloA7ZS1tfH0z2v5VX1zzHLEE/3aKcElO qjKpflIRXOLVSrnngU1NKinUioIzwSiZY1LbEpwfXe+HyZm/3DQaK0asCUPK2iDzi3TP Y9Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771354371; x=1771959171; 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=x46hiGoEyZZRfdFs36nFSz1+AdsW3p14nQ3Wm2zf6Qc=; b=sKSvnsfnjb5iB/PgohfzFFc6+nmJXk/Dto/Wl6i3hAChfm1RiCzh7RtBjtMdGSw1+E JefoHqzpuozwyKehh1nO89/uYyz57gJlOMHfT8w+pY+dBgfzHc2YRiYMx05OJqP3qdHu bjRcD1cBVyILYJL8khz25RnaDJOeq7DmXAdLmFzGrxgp7grdPM3kmV3jYwmSI8v2TZBn TmyVjIxwMyD4qKnTWe79sTpaD+Q69X4i3mV5TozHgfw/mcJH7eLfmJ2AYqFoNMzqzlLU 4MgNmq0sZjh7OpSZgUVw4TPfqgw37sk6gSlUw+wSTAG8SXbPxhBK1cvDingOMHnbND2H 09CA== X-Forwarded-Encrypted: i=1; AJvYcCWAB7stPkfbg/OEGcJdGtzn1UdyrgJl6AM+npOzuLDBwPlqgt+mTLUIoi4k78/p+lYBwDC5tp8wPe3kvkQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yz4nuYWY4qA8mwRMx/jw94mh0+PH8ALhMMQw9xvGq+JLBHDg063 e3of6MQO9Ikg4o8u5ScOL3sYpXhrHG55jZ6034eGAP3HfCvTmuKiWiHFSPaz21RouY8= X-Gm-Gg: AZuq6aKAQIBljCdQNOKvzH4ocGmW8DDcPB6lUjrd6mKwKsIphDzyzvpecCIwZL4Fr6j zXyWqXK9bswXiI2cX6QIWfCmRSrtm7VbU1XGbMwR9M/0FXHJtFWk2HkUOh+YJzlhv332MDMPOoB sa6wh2MbPpIGkWMy/NsNHFryY1lF1kpOsZKzbpLhddjBiip4sbr04Byx4WwE2PFO9kVz+u/vjoh 5ox/gdhN/rNsOz9juJyQAV/uff4av+ImgNME5o0zFR9gBaHmDvc+N2cFnMYxCOtJaEzYa9HK3O4 lR1EDtHWkYzH0/WQRxSszDBS/4Tml0MvzsLfRi7IlrgIcJYrovmHvt0FNv0Uoon+yFYph+a86fi n0XBvAVYEzGE/JTfO1mWbPLthi1Gu/gJ7oQfED62tVs4lYLZbbHyEmOPJCHTUMnlJx57qgSipDT VFhHGViuWukszWhDTiOyiIaGwBXRsVQJVD90/Z X-Received: by 2002:a05:6000:1acc:b0:437:678b:83c2 with SMTP id ffacd0b85a97d-4379793eddamr28020353f8f.54.1771354371131; Tue, 17 Feb 2026 10:52:51 -0800 (PST) Received: from localhost (109-81-87-131.rct.o2.cz. [109.81.87.131]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43796acf5b9sm34218187f8f.34.2026.02.17.10.52.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Feb 2026 10:52:50 -0800 (PST) Date: Tue, 17 Feb 2026 19:52:49 +0100 From: Michal Hocko To: "JP Kobryn (Meta)" Cc: linux-mm@kvack.org, apopple@nvidia.com, akpm@linux-foundation.org, axelrasmussen@google.com, byungchul@sk.com, cgroups@vger.kernel.org, david@kernel.org, eperezma@redhat.com, gourry@gourry.net, jasowang@redhat.com, hannes@cmpxchg.org, joshua.hahnjy@gmail.com, Liam.Howlett@oracle.com, linux-kernel@vger.kernel.org, lorenzo.stoakes@oracle.com, matthew.brost@intel.com, mst@redhat.com, rppt@kernel.org, muchun.song@linux.dev, zhengqi.arch@bytedance.com, rakie.kim@sk.com, roman.gushchin@linux.dev, shakeel.butt@linux.dev, surenb@google.com, virtualization@lists.linux.dev, vbabka@suse.cz, weixugc@google.com, xuanzhuo@linux.alibaba.com, ying.huang@linux.alibaba.com, yuanchu@google.com, ziy@nvidia.com, kernel-team@meta.com Subject: Re: [PATCH 1/2] mm/mempolicy: track page allocations per mempolicy Message-ID: References: <20260212045109.255391-1-inwardvessel@gmail.com> <20260212045109.255391-2-inwardvessel@gmail.com> <3fe7c5dd-b184-4421-a21c-bafce6aa7b09@gmail.com> <9ae80317-f005-474c-9da1-95462138f3c6@gmail.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: On Tue 17-02-26 10:19:08, JP Kobryn (Meta) wrote: > On 2/17/26 4:37 AM, Michal Hocko wrote: > > On Mon 16-02-26 23:48:42, JP Kobryn (Meta) wrote: > > > On 2/16/26 1:07 PM, Michal Hocko wrote: > > [...] > > > > [*] btw. I believe you misaccount MPOL_LOCAL because you attribute the > > > > target node even when the allocation is from a remote node from the > > > > "local" POV. > > > > > > It's a good point. The accounting as a result of fallback cases > > > shouldn't detract from an investigation though. We're interested in the > > > node(s) under pressure so the relatively few fallback allocations would > > > land on nodes that are not under pressure and could be viewed as > > > acceptable noise. > > > > This is really confusing. You simply have no means to tell the > > difference between the requested node and the real node used so you > > cannot really say whether the memory pressure is because of fallbacks or > > your mempolicy configurations. That means that you cannot tell the > > difference between the source of the pressure and victim of that > > pressure. > > What if I excluded the fallback cases? I could get the actual node from > the allocated page and compare against the requested node or node mask. I think it would make sense to send the per-node reclaim stats separately as there doesn't seem to be any dispute about that. For mempolicy stats try to define semantic for each mempolicy first. What exactly do you miss from existing numa_*? Do you want to count number of requests/successes. Do you want to track failures? In what kind of granularity (track fallback nodes)? -- Michal Hocko SUSE Labs