From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66A98C28B2E for ; Mon, 10 Mar 2025 12:26:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 61BA1280004; Mon, 10 Mar 2025 08:26:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A418280002; Mon, 10 Mar 2025 08:26:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44738280004; Mon, 10 Mar 2025 08:26:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 26FA8280002 for ; Mon, 10 Mar 2025 08:26:52 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 792A5160ED3 for ; Mon, 10 Mar 2025 12:26:54 +0000 (UTC) X-FDA: 83205565548.24.A2BA843 Received: from invmail4.hynix.com (exvmail4.skhynix.com [166.125.252.92]) by imf22.hostedemail.com (Postfix) with ESMTP id D4DBCC0005 for ; Mon, 10 Mar 2025 12:26:51 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of honggyu.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=honggyu.kim@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741609612; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MqlVWhOeYlEAf/pKcva9dnZQKHmN2XI2RrYSwZA9dfk=; b=uIzHvZNMj7q6JJXlZsB38Ok0gVoLhMAn29SvKusNV4ee9JQ3MKimrQ4qD1UaBIBz/u77hG otjzpQuXwrhFU7B6k91Y/tGdbVXkYlu69j0gN0hG8IAFWvW2cyi4m5dl8qEhEqPGL6Pl0A pMQJO5WeKW0wa6tFb/cKw/6C3Awr73M= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of honggyu.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=honggyu.kim@sk.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741609612; a=rsa-sha256; cv=none; b=zgUTx4qTlniPtDxHtthsjYwWCxaMbb5Iv1fy6mo1YNLFv7ThxkaiQo7WqFGzl73fmIulYg HwbiB/gKcATkhH1kwPXKsIzT6DgOdDTYpXz7CLt6Kpi4VVAcvW+vNeKVEDoluVimvfp+kS BE2R9WvusCIEdVL8PX89XYa8nwiJLcM= X-AuditID: a67dfc5b-3e1ff7000001d7ae-93-67ceda89a610 Message-ID: <9caca3a8-280a-45bd-a081-cf4a28f05f21@sk.com> Date: Mon, 10 Mar 2025 21:26:48 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Honggyu Kim Subject: Re: [PATCH 2/2 v6] mm/mempolicy: Don't create weight sysfs for memoryless nodes To: Gregory Price Cc: kernel_team@skhynix.com, Joshua Hahn , harry.yoo@oracle.com, ying.huang@linux.alibaba.com, gregkh@linuxfoundation.org, rakie.kim@sk.com, akpm@linux-foundation.org, rafael@kernel.org, lenb@kernel.org, dan.j.williams@intel.com, Jonathan.Cameron@huawei.com, dave.jiang@intel.com, horen.chuang@linux.dev, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com, yunjeong.mun@sk.com References: <20250226213518.767670-1-joshua.hahnjy@gmail.com> <20250226213518.767670-2-joshua.hahnjy@gmail.com> <9c0d8aa8-cac7-4679-aece-af88e8129345@sk.com> Content-Language: ko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsXC9ZZnoW7nrXPpBpOmKVjMWb+GzWL61AuM FiduNrJZ/Lx7nN2iefF6NovVm3wt7i97xmJxu/8cq8WqhdfYLI5vncduse8iUMPOh2/ZLJbv 62e0uLxrDpvFvTX/WS3mfpnKbLF6TYaDoMfhN++ZPXbOusvu0d12md2j5chbVo/Fe14yeWxa 1cnmsenTJHaPEzN+s3jsfGjpsbBhKrPH/rlr2D3OXazw+Pj0FovH501yAXxRXDYpqTmZZalF +nYJXBlbnh9mLpguUjF95lGWBsZ1/F2MnBwSAiYSN+bvZoexN05qZwaxeQUsJfa++8oCYrMI qEq8m9XABhEXlDg58wlYXFRAXuL+rRlgvWwCahJXXk5iArGFBaIkdr76C2RzcIgA9bZdce9i 5OJgFnjMLPHpThcziCMk0MoscXnPBLAGZgERidmdbWCLOQXMJC7NWMUGETeT6NraxQhhy0ts fzsHrFlC4Bq7xOoXZxkhrpaUOLjiBssERsFZSA6chWTuLCSzZiGZtYCRZRWjUGZeWW5iZo6J XkZlXmaFXnJ+7iZGYBwvq/0TvYPx04XgQ4wCHIxKPLwP5p1NF2JNLCuuzD3EKMHBrCTCe/DK uXQh3pTEyqrUovz4otKc1OJDjNIcLErivEbfylOEBNITS1KzU1MLUotgskwcnFINjKv+BC6v CNapLvqqYJC/ysU8a6HV9okfgn8uePPztF3R7MIdHAdEhX3aaz+Z6DBP7n48qyTGL6Q199Gu HFHrzdHBE3LuhvTamh7VW7bh+NK3f/pnhDYZncuYVeC8xCeEV0PdYZ3l/hSFtKtlGzqlklOk dp6Q17lx4u6k5zciBaetPaa220eJXYmlOCPRUIu5qDgRAFOaNt3fAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsXCNUNLT7fz1rl0gzet3BZz1q9hs5g+9QKj xYmbjWwWP+8eZ7doXryezWL1Jl+L+8uesVjc7j/HarFq4TU2i+Nb57Fb7LsI1HB47klWi50P 37JZLN/Xz2hxedccNot7a/6zWsz9MpXZ4tC156wWq9dkWPzetoLNQcTj8Jv3zB47Z91l9+hu u8zu0XLkLavH4j0vmTw2repk89j0aRK7x4kZv1k8dj609FjYMJXZY//cNewe5y5WeHx8eovF 49ttD4/FLz4weXzeJBcgEMVlk5Kak1mWWqRvl8CVseX5YeaC6SIV02ceZWlgXMffxcjJISFg IrFxUjsziM0rYCmx991XFhCbRUBV4t2sBjaIuKDEyZlPwOKiAvIS92/NYAex2QTUJK68nMQE YgsLREnsfPUXyObgEAHqbbvi3sXIxcEs8JhZ4tOdLmYQR0iglVni8p4JYA3MAiISszvbwBZz CphJXJqxig0ibibRtbWLEcKWl9j+dg7zBEa+WUjumIWkfRaSlllIWhYwsqxiFMnMK8tNzMwx 1SvOzqjMy6zQS87P3cQIjNhltX8m7mD8ctn9EKMAB6MSD++DeWfThVgTy4orcw8xSnAwK4nw HrxyLl2INyWxsiq1KD++qDQntfgQozQHi5I4r1d4aoKQQHpiSWp2ampBahFMlomDU6qBkZNn W67wvRK35YkfWJiL+mdxn9i5+OEqB76CbTunX5J7XXm3Z//6ae4t05t26fee5FiRvPCJjOau KDbj7595y3YyOn+3Yn/jdMMw8NmN691ah7f+e/Rg05u4j+H23VNPWH8Tr/IsOhC8a8p5Sy4G RRnJDrb9X62sIidIB/Y+/WLJa3ni5pO2Z0osxRmJhlrMRcWJANJP0sPUAgAA X-CFilter-Loop: Reflected X-Stat-Signature: 9tacdot9yns8am1a9otsdrw9zno4hkqh X-Rspam-User: X-Rspamd-Queue-Id: D4DBCC0005 X-Rspamd-Server: rspam01 X-HE-Tag: 1741609611-313535 X-HE-Meta: U2FsdGVkX1+MXPpNsA4MN6pZSy0KTPCTje0K5hCJGgytyQV6w5vPIdMBzXYoQU5q4aYOZTNZOTQep8mSGYS5M7iMfyXrUwe4VYEyJljpRrIvX0Cl+hXgTV/aQcnrj6jFJdc5GCg0royLmEAuAELqby7oMGey5Zr62rlP+gTRC0MrHz/dlj5TTRnQwGH1tf7EYtPyhLUMfJZmAFpeuHi8g0PKejEDI5PU9t2UZ9S9nlKRvCqCFUaV9ECpxCCUAbx8GVQHe+P/BHCqNPrXnsSmxYVoDbhoFLGbPqFPeTudHNMiCiHsRQxIRS5kcJBqWYt+0IPVWui2X5fXA1wxFZ4JtSwoUlaWbRhEV+WOUAMF+WtF4euVV13VybkT+Gbxg88Udcrf5aEIH/jrn6QlCg8bRjFL0+vbj3/AS5iZ6vbLvMN5UmwB/5a599oHSo6J6T733F/DpSb+oWE/TP+BFaliocAFHLSnkPDZWMiSx6/3CXsb9rJQwC9pizeLzBoN/GV0VS2L62TXNNjKoVOlzROXAbUTJhE+1NWh+X/yvhkts5KJKQUEOXndq84pNee+kLoaoATINb7ODrr9UdCcaBS+dUcQlQq+oGRFDCAKxRDrl4PDzVjvsMJAQMvSQaQZ9yuzKny+d5WVGvFEH+WEjnThe0HBCWcNW8RTndPvUHs505Y9IR8f1qxgzRAkPTlul34ZedlyYV5lhjX27Ra6bezfjeHh5CSPYVYrc2xeHxZ733PlJGPDwyHt2cdkZbYulv3aP+i4DaHqBwFtXWKJkN6YAnFBobxB+i8W7BrDubNI3qHCRfb7FoKjHjkxY553PkWCF+uK/EBbozC0112K25Egf5RBGvrUKX09JMTQ5agJL0uvJEYEuUdhGGS1bIE4t4g8RcV38eqzsJJKpAzmijfJX5skNWLbFVnlee4RQ5pQhvAlAINEfcvJ/puaXvEpTVpW99XNXLWi+FEnTGN9hhp +mgg2YpH K3R03W0DC2vr5qDZiwvUtc4udwIB4gNLbMqbZ6D7b9vyiNxuVWfpFOHVp7EAQZivVB352sHbK2arT77p/wcerVWBRyQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Gregory, On 3/8/2025 2:51 AM, Gregory Price wrote: > On Fri, Mar 07, 2025 at 08:46:46PM +0900, Honggyu Kim wrote: >> You can see more info below. >> >> $ cd /sys/devices/system/node >> >> $ ls -d node* >> node0 node1 node2 node3 >> >> $ cat possible >> 0-11 > > We're split across two threads now, but i'll add this context > > I'm basically asking whether there should be 12 nodes possible. It seems > like there should only be 4 nodes possible - 2 for sockets, 2 for host > bridges. Ack. If the N_POSSIBLE itself becomes 4, then I agree this problem can simply be resolved. > > Unless I'm misunderstanding, it should be the case that a given physical > address can only be hosted by 1 numa node (proximity domain). Yeah, the proximity domain detects the node correctly as follows in dmesg. [ 0.009915] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x7fffffff] [ 0.009917] ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0x207fffffff] [ 0.009919] ACPI: SRAT: Node 1 PXM 1 [mem 0x60f80000000-0x64f7fffffff] [ 0.009924] ACPI: SRAT: Node 2 PXM 6 [mem 0x2080000000-0x807fffffff] hotplug [ 0.009925] ACPI: SRAT: Node 3 PXM 7 [mem 0x64f80000000-0x6cf7fffffff] hotplug It is printed even before CXL detection. > > So it *should* be the case that you either have 4 nodes possible or 10 > nodes possible, not 12. But I could be missing a piece of context. > >> Which command do we need for this info specifically? My output doesn't >> provide some useful info for that. >> >> $ acpidump -b >> $ iasl -d * >> $ cat cedt.dsl >> ... >> **** Unknown ACPI table signature [CEDT] >> > > You probably have an old version of acpidump here, you might need to get > a newer version that knows about the CEDT. I just used the newest acpica and was able to dump CEDT properly. But its output is also very long so it'd be helpful if you could tell us which specific info you need. > > You'll also want to get all the Memory Affinity entries from srat.dsl > >> Not sure about it. This must be fixed ASAP because current kernel is >> broken on this issue and the fix should go into hotfix tree first. >> > > I agree something is broken, I'm not convinced what is broken. Yeah, we should fix the broken status hopefully before v6.14 release. Thanks, Honggyu > >> If you can think this is just a bandaid, but leaving it bleeding as is >> not the right approach. >> > > This affects userland, we shouldn't thrash on this. Lets get it right. > > ~Gregory