From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) (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 0FC8B1C69D for ; Tue, 17 Feb 2026 12:37:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.68 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771331842; cv=none; b=JTPKbT5+3PI0U4o9Ue67PEsFQBZRLTQTdgxPhyAhhJU4HW2mCDWtLuxVY6fw/tt9s5XqL1tJR5qlHqVow34K8uFljsh34BlEiZEmrBHo7L4of6UXgLRsjluX4gzJgGU7PooqRxowJaoWund39IqeOn/b5EFC6hNh8xuDZfAj+Zs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771331842; c=relaxed/simple; bh=0eZcbYVy/RVOWycTRLFEvzMgS8G1c7V8/TBl4IUI77o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JXK/bHBUmCY5MvpQfBoWe0I7JzFK8qlhSvO1N+TISAlQV65CxWBpX2/nuPQlJqf/F7PnL5P3a9S9tI/sYLmoOFNCfZ1J4hDzPS+hajTapILJODQgx0LQvRASb+fMJ5A2aSOY8/mxwLzWk86EQCN5Q/tLoTKi+7gJMKAvX50REng= 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=UPmnRoXf; arc=none smtp.client-ip=209.85.128.68 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="UPmnRoXf" Received: by mail-wm1-f68.google.com with SMTP id 5b1f17b1804b1-4836f363d0dso35889555e9.3 for ; Tue, 17 Feb 2026 04:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771331839; x=1771936639; 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=msDEC8P3Y7O3dfS3sdhcpXjWKe2JYJmxrwEcOrENtGw=; b=UPmnRoXfFk9cE4gD39+4ArCyoUnhwncW35T8OB1KLfRw8woZF13OC4IUD79+9kLZ7r uPuP3wTXC9vKREKrtr2lTibkAkrGIBFjcnU56EchLojk+X562vVsid8xozZnbeZGqH/V Ugm7UyvT+TfbRv/O3Q4kqfVUb+44z+bHW9wfSb9fIgMhbBfipKASusr5RpFcnzEuGtZc h981KQEkMeOgUHH4MYCLibNYv9KUNUiqBPakBZ1sqf8bsTudCdmmXMibpkGEF7ZdczRy /g4WTlKoOgA+Iyj9fd9GdRlOCNOuQBSEOy/lMZbEt1M5MNutmM1tsBjehmoFOIwv85MJ j7Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771331839; x=1771936639; 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=msDEC8P3Y7O3dfS3sdhcpXjWKe2JYJmxrwEcOrENtGw=; b=ZyV6KRY9Y6Z36/qInk9Qrv70x2E/dzAl7t6J6W9tJ82xth8hu1m04bAYp4E86e51xR 4P7kQrllkDQZG2b1pOWIhBGWU+YF6HcbquvIVRslMclK3RetJZfGC3fwyZL0tPcG/oS+ C+Dvh7cFflL5nIQ0kla03dzrV3KPM1pZDptEsKY7OMCF3NqOLkQGcjlrGigDYHhxSFFo nsy37m0B7Ve4fi/s2pQz6JYFblmsXNYDMBopBY4L69ghFW9UNIzM2ctKLJoKB6wGQl4E AM2y+qXWSd1LhAHe7iajvnv+c5yRkRUczniJxyDaC/05bzPLRepTZ5z+uADeVLeM5Upx 9OPw== X-Forwarded-Encrypted: i=1; AJvYcCVmAIU7qA2jSksG8fon9TymoEW8bcshL6cUd0arprcW18Hasjwphc9SI6oTEDr2xmyMO+bKpRt1Wuv6uxA=@vger.kernel.org X-Gm-Message-State: AOJu0YxUyYrPQzBcKkF9Qce3axLIj2kMwuDRiaDRG0ZRQOHArkyrn56z 0+nF2Pi0MvAcX2OH+BND3ugCcLWbrUEP54xODFyzPKEO3Lq27NtjsYkRydcFFWz9eeI= X-Gm-Gg: AZuq6aLNOQzRtYdLnaRhCQFrv0oC2MfIzMW5w2IvqRmTc151sBswmo+XKfMIBfjnfet drZ/s9MUMrhFrbdXMTBF5duJaHrIf+08lUVG5NaFE9izJvxz37ZehlArRukrQpj40AGWzs+koci Bs16QembUow76d0+fv9gfZqgMiHl9vY+b7A1LcZ7I+C9k77LOtmMusoC+9TNoJqzczmTVGa3qUE 8cgJlTQTb93FehjVf4WWN+P3nbOLi90dM6n6w3i0qrsa2fpzDl1VqzMPmc3UtI3svB/rz81Fn8y viL2mgJkNfZrYnw0mHikDz9Mu1CMLs9Q8gMkNZRQ8kbZ0iTuxQ+l4NEpaiA0tw2a2Ol7NYpvdwS Uhc1pJM/CwPEpZq+NZpML0sstifyVeAW0N+Qb+lkA1wJ+iYIODlXth5R8lFWFXMpOT2XLEORLGQ sxcyUbJm53roLlmWfiarL/AqHP3pErqfWzsE38 X-Received: by 2002:a05:600c:6308:b0:47d:586e:2fea with SMTP id 5b1f17b1804b1-48379bc887fmr174214075e9.15.1771331839406; Tue, 17 Feb 2026 04:37:19 -0800 (PST) Received: from localhost (109-81-87-131.rct.o2.cz. [109.81.87.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4836aa0847asm557596855e9.3.2026.02.17.04.37.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Feb 2026 04:37:19 -0800 (PST) Date: Tue, 17 Feb 2026 13:37:17 +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: <9ae80317-f005-474c-9da1-95462138f3c6@gmail.com> 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. I am not saying these scheme doesn't work in your particular setup but I do not see this is long term maintainable thing. It is just too easy to get misleading numbers. If we want/need to track mempolicy allocations better than what existing numa_* counters offer then this needs to be thought through I believe. I do not think we should add these counters in this form. -- Michal Hocko SUSE Labs