From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 0F61F20468E for ; Fri, 13 Mar 2026 03:05:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773371123; cv=none; b=psuL3XkUO3cTlDbL5y4ZNY0Z7IOu8GpgXMl7KdTqCYFaMXKklNANHBe8FWeMRZzYznaDPwflFuCMtDFBDEC5a6IkEpMGhqVA4Lb5whE9/R17HQOW9IGKOYviO0we1jU1oG0bC5rogK5mUll7SJbxsNvZEXdeeyTFHIBUi4u81cU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773371123; c=relaxed/simple; bh=WLsJA/HFpoSz/qJAj3x6z062D0MMeQF1uUYpy271mic=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=iapYBtpdS01dg/1mEiubOL7Bc7l8BgMyHTIp1dfD9Yp46SMd1DCQ+vNdUDBmxWfvfuSDdoRkomR/6qB37deEu4e4CeWfkUwuKWBfPrbGKXrKwHHuP7VdFgeJlbPbUiV34WuF5g8SxLHMZszysbFd+15N+TyEUMJh/oYhZYPdeug= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OdHxAQ7k; arc=none smtp.client-ip=209.85.214.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OdHxAQ7k" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2a9296b3926so13896515ad.1 for ; Thu, 12 Mar 2026 20:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773371121; x=1773975921; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YMiD7iuuQ6RwrA9DHEwvWHHs17Gv5D7sbQEPQSKpbdQ=; b=OdHxAQ7kby3qHb87qB4/Oh6wjqtxy1jsTxRI68sP11dL0LnDbIJvalwJ9jOgbdREp4 WsCHBufVT5pfxFb39f4437VFp5zWWguJhBvF1nKP0zYUoW9YPe+1KeOel9aLRtmxmy0u J+FTc5EwT2LpOyLR8Ic7ja5nK27eldfH75P2u5i/qiN4Gh977q3855pGCO/tKEerhDx6 /MDz3vVUNeLpqDGsSo5htsG6Kjn1uLHPDJFvlXVshz3kwaPKE7MjxYpzibO7z+vj7Mjo k2kIIcQp507PifJ4nt7P3XJ6fxyzWEBmrdXF374QdmfxxlpQlJ3+eQWBR3MDAWqaj6UY 9xrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773371121; x=1773975921; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YMiD7iuuQ6RwrA9DHEwvWHHs17Gv5D7sbQEPQSKpbdQ=; b=fXalW3N7HZuw+mFNrTnsES+QtkRp9dIgSD5oZx0APwJwlV4IQGX1sD+ZYVjd2z2N0B wiNe9Wn54qqRmVAY+xgviaT+XW93QtHg2xetB5JShSe5dgHy4Py1epeQv0RBV5SH4OWf yHGi+gIwT+h7qRq/aJaRbWJkDBex6OIR0GDfpjTif0a6eVLAFVvH9wbL7zwn6ntWy1qh D8J9NaQFMIaRzzlaBTPYXGrePbKHAiuFOatdxc1bMb10LqgLFXTwR9H8edx969QQ1zxS mDD8L1q37v7sfZBQD/gZYqK8oddyZt5fmg5gKx6vGK/pfP+gTS2bT3PVk1aCvqX6c+ST +ZFw== X-Forwarded-Encrypted: i=1; AJvYcCX4Pl2hVUXAYxnob+P6A3K+Unus10GllMIcJM98UKajDwzDPMznXytvOPIYqxWeEwvDogMDjsKZwvOX7RM=@vger.kernel.org X-Gm-Message-State: AOJu0YyEIXEEi3fNiCA3SFSGve9pjr6kt0fCcLLjtSRsTulSj/uekH31 jH6uED/b/WAU4yxCHbC78CQmNPcHbiGedOYCGDEMwX6UQ1p4byi8d7Wu X-Gm-Gg: ATEYQzxOQx6d72WoAtrFxt6nE6thEA7RSXbjvRE6707Ezsl+Ve3BM6w5+kk6L4dryAE s6DOLGB+CzOv65vNo3569U7xwfiJr6mmHJQ8DbCQ/LUa6mpHxgzmcz87IT7j3fDf0egjH77xTDF XTXahmLMqSzLlon836LEBLgJ0+k2LJjz+5pqV59KbXyhUyxe5H52C0Wp+6CSP0pweoYXPxq+jd/ fz6iLkbbqgdOHOQZF6f+nXv48+/bYtvdWtgG64PtmImGwlHNwV/GQPPCDU4S1TGzzXYiaEEmdyc zx/ey4hK2sshax7kcwRrman9plooDo8iaNwpPoqtKrGyah2OZjorpBVJa1Lk08eD6QP/iEupTDs ilz9Vj4/KbSA7MJ0tXWVbTl0F111l7iKGqQVsbdjniX/QPvpR2SXtsWiGoBFERzBGpgmGfe2rlt xvsCc1hVRlVJ0TzadGbxSeU6tvW9SXoOG5UdUY9k30Y/X7Uum/WrgzLvKl7GYJJwtLId+boIHNq w== X-Received: by 2002:a17:903:1a2e:b0:2a0:de4f:c99 with SMTP id d9443c01a7336-2aeca96723cmr15904725ad.9.1773371121407; Thu, 12 Mar 2026 20:05:21 -0700 (PDT) Received: from [192.168.123.240] (n11212047001.netvigator.com. [112.120.47.1]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aece56c388sm5610335ad.11.2026.03.12.20.05.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 20:05:21 -0700 (PDT) Message-ID: <8315168c-0557-445b-aa86-174d9902e2e1@gmail.com> Date: Fri, 13 Mar 2026 11:05:15 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/mempolicy: add sysfs interface to override NUMA node bandwidth To: Jonathan Cameron Cc: akpm@linux-foundation.org, david@kernel.org, dan.j.williams@intel.com, ying.huang@linux.alibaba.com, linux-mm@kvack.org, joshua.hahnjy@gmail.com, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, dave.jiang@intel.com References: <20260312091207.2016518-1-seven.yi.lee@gmail.com> <20260312115825.000045af@huawei.com> Content-Language: en-US From: Yee Li In-Reply-To: <20260312115825.000045af@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jonathan, Thanks for the review. > As I note below, I'm not convinced this is the best layer to be injecting > data at if we want a debug interface that allows us to reflect real > hardware. Might be the sort of patch that is useful outside the tree though > so thanks for sharing it! Perhaps a small tool to compute weights from the desired bandwidth would be a better approach. > If it was an SRAT (for GPs) / HMAT issue I'd suggest table injection is > an adequate way to do testing and debug. > > CDAT is trickier, but maybe we should be thinking about a debug path to inject > that as well - similar to what we do for ACPI tables. > > From my point of view I'd rather see debug / testing interfaces that test the > whole flow rather than just this top layer control. > > However, I can see this is a useful patch for developers. But if you > are developing debugging bandwidth-aware memory policies, I'm going to assume > you don't mind building a kernel and adding this patch to make your life > easier! > > So to me, useful tool but I'm not 'yet' convinced it should be upstream. You are right, table injection is likely the better approach. During early hardware development the platform is often unstable, and firmware may not be able to report it accurately. Letting the OS handle debugging and evaluate the results can make experimentation easier. And, thank you for checking the code.