From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) (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 BD1F627B4FB for ; Mon, 16 Feb 2026 21:07:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771276070; cv=none; b=WLDRUb6s4hQcFGwcV0l5m1g2R5NO8lz+fjd4qLaqEZTJhpRKd0VP6DYG3Bn+Zggko8ERXJ9tUbY6h0xIeIUk6y5ZvkwR2i43J3ZfkUaqvwynThL94f0YHY4O5t+KPpHs4/mc0qjxts6Yu2rwMbZznH7Blnnu8i0c6JBG1XKd6eo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771276070; c=relaxed/simple; bh=ahY9nzIrmb3VN2PNtTKd4XYo5vjVSwt3GAvd5/xCOrA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LXo4k8hGdySiTafCtVPUmOqK8OsalR86jd0StTAVqBT7js6jmpGBNNz4ivSlkb2yrsmiWAd3wWBsx5jfYgPGvCi41iZcFdVaosa4A7aWTeCWq9O8Vu9+Z6vcXDxIalky4GRp7zQcn4MTrZQdPa/IthMzxI3DjNLFAcON6Udmfyg= 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=fyUVW/k3; arc=none smtp.client-ip=209.85.128.65 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="fyUVW/k3" Received: by mail-wm1-f65.google.com with SMTP id 5b1f17b1804b1-48371119eacso32985095e9.2 for ; Mon, 16 Feb 2026 13:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771276067; x=1771880867; 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=HpRBCfCaKwzFeCSlkRPtiCqwRuCq3qQsbgDvpARfGfQ=; b=fyUVW/k3wD+KSJdN1setl/p2qnyMMQ7xCe2vceXlSSP52n4SJttsq3jq6lQ8alW40D UvmjdePyb0tiCljckqV2BCJLu6nAQddgeBdhLAHrI2G4nbPLAl+AJbFjvX4F4ntydn8t PgwycV8vqP+vjZHB9O2S23w4bgpV8n/K0TsA3doCVKbqOPdHjOjmLPRL8DAEMVZaUlpV +lfOw169MsN4x7T0LFLRuWU27B4jpCFz+njbcX5jH89AAbB7MW4Jj2QABA2r2nr4cmBH NyasSNJ/3fqHk5qA6zzrUjmGLtOCLt0xIHwugP74QzyokNrdIySO5xxcISO5vm6g4z2f bLVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771276067; x=1771880867; 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=HpRBCfCaKwzFeCSlkRPtiCqwRuCq3qQsbgDvpARfGfQ=; b=oPVk2Q2z/XbgqbMijTvQQpSEX2QXwpWXkS6VzWSNSvxNF4MokXFCiiIx9Lw+LljjE/ et0GBH3fm45qgEvPfPMIFDpglGm94LuYBN3+l+a1xMQXe5KdMNLm/3RbmOlEeGNQmybD fR9ZMrkWG/l0+Zef58YP2zrcTYJ655m+lvm6rj49F3HNHcpgQgHrEOKUTP4vFJ2fJ6cR g8WVjoeIbWJagzd15HeBj03gus6d0wHTT/bBHqY2xQez4upZyvtmmH3gjjWAEO1NrJBc aCMJ/7KXs6ZagIarQdGXPHUdn/oOEFdetA+mDmeToxnA7EWAT/bN39zjoVtyLdRGmaUP hPCg== X-Forwarded-Encrypted: i=1; AJvYcCV4J5AJKBcbHz1BqGGlGq39XN6tFqsbLJThNHJC9WK8T8mDWDSx3zVGSnh6gCozadxx5NdTqOoNsPmABb4=@vger.kernel.org X-Gm-Message-State: AOJu0YwiRhJAv4/Z5BrSmCgigU/LdO03hMpiGIgWXlzdwpgpFn1sxg0S vxZp1KFw3alyI8MGj0Mn3P5WKH8+GFWmoMYagtTTBdaardvpKqYwgh//omRIYXHZBdI= X-Gm-Gg: AZuq6aINashfeNDPDWan5ENd7zozAGUi5BdIC+WdTQLMcyeJ1c22zLUYg5UNMtEKzQZ nUgAVjIolksKfWBcgmLJEIT8cF/nWdIXlbLGZ1NzLE8BOfUV6gCgCErRGcpKF43nn0/Qkxf2uN9 Q6PkHoydB3pKXYd+/1JF0J2c9T0Qw7+aTyVNsBLaDW0y7oETW8WiZmxTZAqiq+a0D5YYd83XGcV Wht2itV7M2Bp9ASC1IVJAMIrW02ZC/7M5gP0h7uOhyfIRAArhHiAo2T2T98Ngfbns6I4Z5IA7Bb DEHt2QCHd4fDGmTYO3O1oWWnU69sJyV+i0cGG1qGv1SSPWRLXr1zzfRQMrn1uTrUq46z46B06+S HEfR5VbQW8sgmc1+pbb041AUwXQ4+BIjZKDmbSyv2jA6sK2r57W9H4Zq1lUo/gM8vh/VngdS02T MuLeNc37bk6YvWxhJ0i6GjJgSdDPN0FbzpUnGw X-Received: by 2002:a05:600c:19cc:b0:47e:e2ec:995b with SMTP id 5b1f17b1804b1-48373a1271emr193576735e9.9.1771276067044; Mon, 16 Feb 2026 13:07:47 -0800 (PST) Received: from localhost (109-81-87-131.rct.o2.cz. [109.81.87.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4834d5d77b3sm519573895e9.2.2026.02.16.13.07.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 13:07:46 -0800 (PST) Date: Mon, 16 Feb 2026 22:07:45 +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> 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: <3fe7c5dd-b184-4421-a21c-bafce6aa7b09@gmail.com> On Mon 16-02-26 09:50:26, JP Kobryn (Meta) wrote: > On 2/16/26 12:26 AM, Michal Hocko wrote: > > On Thu 12-02-26 13:22:56, JP Kobryn wrote: > > > On 2/11/26 11:29 PM, Michal Hocko wrote: > > > > On Wed 11-02-26 20:51:08, JP Kobryn wrote: > > > > > It would be useful to see a breakdown of allocations to understand which > > > > > NUMA policies are driving them. For example, when investigating memory > > > > > pressure, having policy-specific counts could show that allocations were > > > > > bound to the affected node (via MPOL_BIND). > > > > > > > > > > Add per-policy page allocation counters as new node stat items. These > > > > > counters can provide correlation between a mempolicy and pressure on a > > > > > given node. > > > > > > > > Could you be more specific how exactly do you plan to use those > > > > counters? > > > > > > Yes. Patch 2 allows us to find which nodes are undergoing reclaim. Once > > > we identify the affected node(s), the new mpol counters (this patch) > > > allow us correlate the pressure to the mempolicy driving it. > > > > I would appreciate somehow more specificity. You are adding counters > > that are not really easy to drop once they are in. Sure we have > > precedence of dropping some counters in the past so this is not as hard > > as usual userspace APIs but still... > > > > How exactly do you tolerate mempolicy allocations to specific nodes? > > While MPOL_MBIND is quite straightforward others are less so. > > The design does account for this regardless of the policy. In the call > to __mod_node_page_state(), I'm using page_pgdat(page) so the stat is > attributed to the node where the page actually landed. That much is clear[*]. The consumer side of things is not really clear to me. How do you know which policy or part of the nodemask of that policy is the source of the memory pressure on a particular node? In other words how much is the data actually useful except for a single node mempolicy (i.e. MBIND). [*] 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. -- Michal Hocko SUSE Labs