From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) (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 833C22F60A7 for ; Mon, 16 Feb 2026 08:26:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.67 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771230367; cv=none; b=YhUSpG6R8TNctE+XkYAwQOHz4a+ZSfVLXZl1llfE4jWpzhJeVuAeB/meQwqAcSK7bLFClFx+gF4pjirUZtRzVcFyTt0r6Tp1jshCo++YfQ9zhclzNY1MF0N6N+QlGyFP6Oh6kZKr663tYOWEBExuyHqxE9HTaD3OHYsvfYzFgxk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771230367; c=relaxed/simple; bh=lVYcW124xXUpGqImemRfOTuqz9/8KIKwr6TZK67q7ac=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hwfR/1W7dPPVRzAQR6ml9XMVtNtPdO7VnjcGb3AsNB9+1zc2NZdAJy3CbifR++ZqliFvS459xEUl2ZgfY/GuxTm1Ck7pVBzkcHDrB2jxp+JBHW33jAnZoziBkQdYLhpdMfWlcID1aB9gLVKfMtQGX+soNtLqWFjyDvG/Of4l/Fk= 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=Wk1808iE; arc=none smtp.client-ip=209.85.128.67 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="Wk1808iE" Received: by mail-wm1-f67.google.com with SMTP id 5b1f17b1804b1-48371bb515eso31691875e9.1 for ; Mon, 16 Feb 2026 00:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771230365; x=1771835165; 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=Xb3Y5mpUx/KX/i4KodCYFSkUEnbxPYW1NpgmoLibx/U=; b=Wk1808iEY47Igz+FN0gG9ttvtUP29bgVI8DKINBj9fwDauyN0DnxBIpiUUp5Hs435g /j9lUqzcnVZehsXAA9c+NECUDnI2rST4rz07vFt0biGrBTITUTnU9ZkRIOjQHdLFEY15 Mjclt0uXbXbYDoN5oqWhnH7atps7IuzMOzi9JEOKZA4f1gd/5T/LoH/utPkHDb0jOd2b LecL+egjWtO21y4aNqYz2wCHuwXThWe5TeQ3MEo6+UE+TVRfaYpbxCuSjtaqR23uJ/Dz rnOwdq4C5GDA/JYps0YhU9UM8dxIcKnd/EZD/YRrNSuXN2eXpFFoRsqlI4HxOp7HQSau O1vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771230365; x=1771835165; 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=Xb3Y5mpUx/KX/i4KodCYFSkUEnbxPYW1NpgmoLibx/U=; b=WWwj0cAEZAssgyD3gp/ZN+VRmP8ozUyxTKesEB7NghpGbHIKtOZbtjwmkVeWyI1wne IMyMqNogT7Gx3yKqpGYYK9hNHORA9fE+UNA8mZcRG5fGfryikYzKBRciirbPJ1nQiZ3W friuv+ff9celcjx1cU8f8a5QF5Ejm0FWqKAYbDm6zAL6nNcsS+WWY+Dq/PChvuwgd9nd 7cZ6gOJEfeFYk4/4hvoz9+Hf5xkijbsmsJP0fucjZ20j2eg1heN+00kJ7Ws7oKVVBcmP micO+IuHuDZfN4U8bb9ZkDCScbZXBfFg3lNMKOnYwhbRaVlwQ7PjfQu9AmwPhIGbErtg jx1Q== X-Forwarded-Encrypted: i=1; AJvYcCU95H0S2/0M4KI66IklhjZ/Muen/s0AjUNicgO5nXzui9OAvhAURz2jHW1ur1WcVefvfNMigrAcFKn7fP8=@vger.kernel.org X-Gm-Message-State: AOJu0YwoIztEFhmigk/k3S+90pRDWnEQ5laTup3jZYEL5i52dVgjfFJQ ExD6HNi7cc8OReCL8aVbro9ogL56WR6eN5MNdEFSsfFx/6N6b9nXRGuQIsALadbicd4= X-Gm-Gg: AZuq6aK12WDr9VcYNRH43rp7R90InmKf2IznR7SNEq0rIcy8Vq50pM5P6bN2visrrfj nvUl4hdJZUu2y++DXvudOWzrKMY4Myl2VcDYiK7wfL1s/suC4mBpWPo/to2dsIGXdKKuKPZ150x Rv2BXHSFP5wcEVjdYS+ScvrNkv3ce6wB8Rek0A1TE3IYsSzptey6ast7EVnIhBPmt/HDnBa0ZMS L0AHyUMdBnrUc6lArQLW9hsB/70FpeLnbJCKSlikrFlKmn3eso8AIBEin+wk/RpNGy5e/3iPsvv zHWNWtCTROYodt07kWP0BcsrdthaPmSTE2nPB95mw5HxIUYjrU+GeH4DPCRhWQ/XFh0WWfW7k58 TDLnMhktejpravjYlYHy+cenSqX+uh0Fjiv1qPUNl175gF42VbywmaNQ2RmNuFh43idMcPJgwL5 fdFk0cSbG8c2Zh4clhItIOJbd2wIDMwFRrd3eP X-Received: by 2002:a05:600c:c170:b0:480:4a90:1afe with SMTP id 5b1f17b1804b1-48373a78d47mr149302415e9.34.1771230364694; Mon, 16 Feb 2026 00:26:04 -0800 (PST) Received: from localhost (109-81-87-131.rct.o2.cz. [109.81.87.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48371a337dfsm81435315e9.19.2026.02.16.00.26.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 00:26:04 -0800 (PST) Date: Mon, 16 Feb 2026 09:26:03 +0100 From: Michal Hocko To: JP Kobryn 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> 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 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. -- Michal Hocko SUSE Labs