From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: "Ho-Ren (Jack) Chuang" <horen.chuang@linux.dev>,
Gregory Price <gourry.memverge@gmail.com>,
<aneesh.kumar@linux.ibm.com>, <mhocko@suse.com>, <tj@kernel.org>,
<john@jagalactic.com>, Eishan Mirakhur <emirakhur@micron.com>,
Vinicius Tavares Petrucci <vtavarespetr@micron.com>,
Ravis OpenSrc <Ravis.OpenSrc@micron.com>,
Alistair Popple <apopple@nvidia.com>,
Srinivasulu Thanneeru <sthanneeru@micron.com>,
SeongJae Park <sj@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Jiang <dave.jiang@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
<linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-mm@kvack.org>, "Ho-Ren (Jack) Chuang" <horenc@vt.edu>,
"Ho-Ren (Jack) Chuang" <horenchuang@bytedance.com>,
"Ho-Ren (Jack) Chuang" <horenchuang@gmail.com>,
<linux-cxl@vger.kernel.org>, <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2 1/1] memory tier: consolidate the initialization of memory tiers
Date: Thu, 4 Jul 2024 18:09:51 +0100 [thread overview]
Message-ID: <20240704180951.00005ca6@Huawei.com> (raw)
In-Reply-To: <87a5iykgdf.fsf@yhuang6-desk2.ccr.corp.intel.com>
On Wed, 03 Jul 2024 16:51:40 +0800
"Huang, Ying" <ying.huang@intel.com> wrote:
> Jonathan Cameron <Jonathan.Cameron@Huawei.com> writes:
>
> > On Fri, 28 Jun 2024 06:09:23 +0000
> > "Ho-Ren (Jack) Chuang" <horen.chuang@linux.dev> wrote:
>
> [snip]
>
> >> @@ -875,8 +886,7 @@ static int __meminit memtier_hotplug_callback(struct notifier_block *self,
> >>
> >> static int __init memory_tier_init(void)
> >> {
> >> - int ret, node;
> >> - struct memory_tier *memtier;
> >> + int ret;
> >>
> >> ret = subsys_virtual_register(&memory_tier_subsys, NULL);
> >> if (ret)
> >> @@ -887,7 +897,8 @@ static int __init memory_tier_init(void)
> >> GFP_KERNEL);
> >> WARN_ON(!node_demotion);
> >> #endif
> >> - mutex_lock(&memory_tier_lock);
> >> +
> >> + guard(mutex)(&memory_tier_lock);
> >
> > If this was safe to do without the rest of the change (I think so)
> > then better to pull that out as a trivial precursor so less noise
> > in here.
> >
> >> /*
> >> * For now we can have 4 faster memory tiers with smaller adistance
> >> * than default DRAM tier.
> >> @@ -897,29 +908,9 @@ static int __init memory_tier_init(void)
> >> if (IS_ERR(default_dram_type))
> >> panic("%s() failed to allocate default DRAM tier\n", __func__);
> >>
> >> - /*
> >> - * Look at all the existing N_MEMORY nodes and add them to
> >> - * default memory tier or to a tier if we already have memory
> >> - * types assigned.
> >> - */
> >> - for_each_node_state(node, N_MEMORY) {
> >> - if (!node_state(node, N_CPU))
> >> - /*
> >> - * Defer memory tier initialization on
> >> - * CPUless numa nodes. These will be initialized
> >> - * after firmware and devices are initialized.
> >> - */
> >> - continue;
> >> -
> >> - memtier = set_node_memory_tier(node);
> >> - if (IS_ERR(memtier))
> >> - /*
> >> - * Continue with memtiers we are able to setup
> >> - */
> >> - break;
> >> - }
> >> - establish_demotion_targets();
> >> - mutex_unlock(&memory_tier_lock);
> >> + /* Record nodes with memory and CPU to set default DRAM performance. */
> >> + nodes_and(default_dram_nodes, node_states[N_MEMORY],
> >> + node_states[N_CPU]);
> >
> > There are systems where (for various esoteric reasons, such as describing an
> > association with some other memory that isn't DRAM where the granularity
> > doesn't match) the CPU nodes contain no DRAM but rather it's one node away.
> > Handling that can be a job for another day though.
> >
> > Why does this need to be computed here? Why not do it in
> > hmat_set_default_dram_perf? Doesn't seem to be used anywhere else.
>
> IMO, which node is default dram node is a general concept instead of
> HMAT specific. So, I think that it's better to decide that in the
> general code (memory-tiers.c).
That makes sense given I'd imagine this will spread to other firmware
types in time.
Thanks,
Jonathan
>
> >>
> >> hotplug_memory_notifier(memtier_hotplug_callback, MEMTIER_HOTPLUG_PRI);
> >> return 0;
>
> --
> Best Regards,
> Huang, Ying
>
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: "Ho-Ren (Jack) Chuang" <horen.chuang@linux.dev>,
Gregory Price <gourry.memverge@gmail.com>,
<aneesh.kumar@linux.ibm.com>, <mhocko@suse.com>, <tj@kernel.org>,
<john@jagalactic.com>, Eishan Mirakhur <emirakhur@micron.com>,
Vinicius Tavares Petrucci <vtavarespetr@micron.com>,
Ravis OpenSrc <Ravis.OpenSrc@micron.com>,
Alistair Popple <apopple@nvidia.com>,
Srinivasulu Thanneeru <sthanneeru@micron.com>,
SeongJae Park <sj@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Jiang <dave.jiang@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
<linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-mm@kvack.org>, "Ho-Ren (Jack) Chuang" <horenc@vt.edu>,
"Ho-Ren (Jack) Chuang" <horenchuang@bytedance.com>,
"Ho-Ren (Jack) Chuang" <horenchuang@gmail.com>,
<linux-cxl@vger.kernel.org>, <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2 1/1] memory tier: consolidate the initialization of memory tiers
Date: Thu, 4 Jul 2024 18:09:51 +0100 [thread overview]
Message-ID: <20240704180951.00005ca6@Huawei.com> (raw)
In-Reply-To: <87a5iykgdf.fsf@yhuang6-desk2.ccr.corp.intel.com>
On Wed, 03 Jul 2024 16:51:40 +0800
"Huang, Ying" <ying.huang@intel.com> wrote:
> Jonathan Cameron <Jonathan.Cameron@Huawei.com> writes:
>
> > On Fri, 28 Jun 2024 06:09:23 +0000
> > "Ho-Ren (Jack) Chuang" <horen.chuang@linux.dev> wrote:
>
> [snip]
>
> >> @@ -875,8 +886,7 @@ static int __meminit memtier_hotplug_callback(struct notifier_block *self,
> >>
> >> static int __init memory_tier_init(void)
> >> {
> >> - int ret, node;
> >> - struct memory_tier *memtier;
> >> + int ret;
> >>
> >> ret = subsys_virtual_register(&memory_tier_subsys, NULL);
> >> if (ret)
> >> @@ -887,7 +897,8 @@ static int __init memory_tier_init(void)
> >> GFP_KERNEL);
> >> WARN_ON(!node_demotion);
> >> #endif
> >> - mutex_lock(&memory_tier_lock);
> >> +
> >> + guard(mutex)(&memory_tier_lock);
> >
> > If this was safe to do without the rest of the change (I think so)
> > then better to pull that out as a trivial precursor so less noise
> > in here.
> >
> >> /*
> >> * For now we can have 4 faster memory tiers with smaller adistance
> >> * than default DRAM tier.
> >> @@ -897,29 +908,9 @@ static int __init memory_tier_init(void)
> >> if (IS_ERR(default_dram_type))
> >> panic("%s() failed to allocate default DRAM tier\n", __func__);
> >>
> >> - /*
> >> - * Look at all the existing N_MEMORY nodes and add them to
> >> - * default memory tier or to a tier if we already have memory
> >> - * types assigned.
> >> - */
> >> - for_each_node_state(node, N_MEMORY) {
> >> - if (!node_state(node, N_CPU))
> >> - /*
> >> - * Defer memory tier initialization on
> >> - * CPUless numa nodes. These will be initialized
> >> - * after firmware and devices are initialized.
> >> - */
> >> - continue;
> >> -
> >> - memtier = set_node_memory_tier(node);
> >> - if (IS_ERR(memtier))
> >> - /*
> >> - * Continue with memtiers we are able to setup
> >> - */
> >> - break;
> >> - }
> >> - establish_demotion_targets();
> >> - mutex_unlock(&memory_tier_lock);
> >> + /* Record nodes with memory and CPU to set default DRAM performance. */
> >> + nodes_and(default_dram_nodes, node_states[N_MEMORY],
> >> + node_states[N_CPU]);
> >
> > There are systems where (for various esoteric reasons, such as describing an
> > association with some other memory that isn't DRAM where the granularity
> > doesn't match) the CPU nodes contain no DRAM but rather it's one node away.
> > Handling that can be a job for another day though.
> >
> > Why does this need to be computed here? Why not do it in
> > hmat_set_default_dram_perf? Doesn't seem to be used anywhere else.
>
> IMO, which node is default dram node is a general concept instead of
> HMAT specific. So, I think that it's better to decide that in the
> general code (memory-tiers.c).
That makes sense given I'd imagine this will spread to other firmware
types in time.
Thanks,
Jonathan
>
> >>
> >> hotplug_memory_notifier(memtier_hotplug_callback, MEMTIER_HOTPLUG_PRI);
> >> return 0;
>
> --
> Best Regards,
> Huang, Ying
>
next prev parent reply other threads:[~2024-07-04 17:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 6:09 [PATCH v2 0/1] memory tier: consolidate the initialization of memory tiers Ho-Ren (Jack) Chuang
2024-06-28 6:09 ` [PATCH v2 1/1] " Ho-Ren (Jack) Chuang
2024-07-01 5:13 ` Huang, Ying
2024-07-02 5:37 ` Ho-Ren (Jack) Chuang
2024-07-02 13:25 ` Jonathan Cameron
2024-07-02 13:25 ` Jonathan Cameron via
2024-07-03 8:33 ` Ho-Ren (Jack) Chuang
2024-07-04 17:08 ` Jonathan Cameron
2024-07-04 17:08 ` Jonathan Cameron via
2024-07-03 8:51 ` Huang, Ying
2024-07-04 17:09 ` Jonathan Cameron [this message]
2024-07-04 17:09 ` Jonathan Cameron via
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240704180951.00005ca6@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Ravis.OpenSrc@micron.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=apopple@nvidia.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=emirakhur@micron.com \
--cc=gourry.memverge@gmail.com \
--cc=horen.chuang@linux.dev \
--cc=horenc@vt.edu \
--cc=horenchuang@bytedance.com \
--cc=horenchuang@gmail.com \
--cc=john@jagalactic.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=qemu-devel@nongnu.org \
--cc=rafael@kernel.org \
--cc=sj@kernel.org \
--cc=sthanneeru@micron.com \
--cc=tj@kernel.org \
--cc=vtavarespetr@micron.com \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.