[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <696571507b075_20718100d4@dwillia2-mobl4.notmuch>
Date: Mon, 12 Jan 2026 14:10:24 -0800
From: <dan.j.williams@...el.com>
To: Balbir Singh <balbirs@...dia.com>, <dan.j.williams@...el.com>, Yury Norov
<ynorov@...dia.com>, Gregory Price <gourry@...rry.net>
CC: <linux-mm@...ck.org>, <cgroups@...r.kernel.org>,
<linux-cxl@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
<kernel-team@...a.com>, <longman@...hat.com>, <tj@...nel.org>,
<hannes@...xchg.org>, <mkoutny@...e.com>, <corbet@....net>,
<gregkh@...uxfoundation.org>, <rafael@...nel.org>, <dakr@...nel.org>,
<dave@...olabs.net>, <jonathan.cameron@...wei.com>, <dave.jiang@...el.com>,
<alison.schofield@...el.com>, <vishal.l.verma@...el.com>,
<ira.weiny@...el.com>, <akpm@...ux-foundation.org>, <vbabka@...e.cz>,
<surenb@...gle.com>, <mhocko@...e.com>, <jackmanb@...gle.com>,
<ziy@...dia.com>, <david@...nel.org>, <lorenzo.stoakes@...cle.com>,
<Liam.Howlett@...cle.com>, <rppt@...nel.org>, <axelrasmussen@...gle.com>,
<yuanchu@...gle.com>, <weixugc@...gle.com>, <yury.norov@...il.com>,
<linux@...musvillemoes.dk>, <rientjes@...gle.com>, <shakeel.butt@...ux.dev>,
<chrisl@...nel.org>, <kasong@...cent.com>, <shikemeng@...weicloud.com>,
<nphamcs@...il.com>, <bhe@...hat.com>, <baohua@...nel.org>,
<yosry.ahmed@...ux.dev>, <chengming.zhou@...ux.dev>,
<roman.gushchin@...ux.dev>, <muchun.song@...ux.dev>, <osalvador@...e.de>,
<matthew.brost@...el.com>, <joshua.hahnjy@...il.com>, <rakie.kim@...com>,
<byungchul@...com>, <ying.huang@...ux.alibaba.com>, <apopple@...dia.com>,
<cl@...two.org>, <harry.yoo@...cle.com>, <zhengqi.arch@...edance.com>
Subject: Re: [RFC PATCH v3 0/8] mm,numa: N_PRIVATE node isolation for
device-managed memory
Balbir Singh wrote:
[..]
> > I agree with Gregory the name does not matter as much as the
> > documentation explaining what the name means. I am ok if others do not
> > sign onto the rationale for why not include _MEMORY, but lets capture
> > something that tries to clarify that this is a unique node state that
> > can have "all of the above" memory types relative to the existing
> > _MEMORY states.
> >
>
> To me, N_ is a common prefix, we do have N_HIGH_MEMORY, N_NORMAL_MEMORY.
> N_PRIVATE does not tell me if it's CPU or memory related.
True that confusion about whether N_PRIVATE can apply to CPUs is there.
How about split the difference and call this:
N_MEM_PRIVATE
To make it both distinct from _MEMORY and _HIGH_MEMORY which describe
ZONE limitations and distinct from N_CPU.
Powered by blists - more mailing lists