From: Gregory Price <gourry@gourry.net>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com, akpm@linux-foundation.org, ziy@nvidia.com,
joshua.hahnjy@gmail.com, rakie.kim@sk.com,
ying.huang@linux.alibaba.com, honggyu.kim@sk.com,
stable@vger.kernel.org
Subject: Re: [PATCH] mm/mempolicy: recompute automatic interleave weights on memory hotplug
Date: Mon, 26 Oct 2026 11:47:46 -0400 [thread overview]
Message-ID: <at91WFlW96PH-a8A@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <e3a1ae72-9370-4c3c-8935-6a410a74377b@kernel.org>
On Mon, Oct 26, 2026 at 12:19:21PM +0100, David Hildenbrand (Arm) wrote:
> > +/* Recompute the weights from node_bw_table, unless they were set manually */
> > +static int wi_state_refresh(void)
> > +{
> > + struct weighted_interleave_state *new_wi_state, *old_wi_state;
> > + int i;
> > +
> > + new_wi_state = kmalloc_flex(*new_wi_state, iw_table, nr_node_ids);
> > + if (!new_wi_state)
> > + return -ENOMEM;
> > + new_wi_state->mode_auto = true;
> > + for (i = 0; i < nr_node_ids; i++)
> > + new_wi_state->iw_table[i] = 1;
> > +
> > + mutex_lock(&wi_state_lock);
> > + old_wi_state = rcu_dereference_protected(wi_state,
> > + lockdep_is_held(&wi_state_lock));
> > + /* NULL wi_state assumes auto=true */
> > + if (!node_bw_table || (old_wi_state && !old_wi_state->mode_auto)) {
>
>
> I was confused about the node_bw_table check at first. Maybe
>
> /*
> * We can get hotplug events before any BW data was recorded.
> * ...
> */
>
I went back and forth on whether to do the mutex in or outside this
function, but ultimately decided inside is just better structurally.
But yes, this comment seems warranted in this case.
> > + /*
> > + * HMAT and CXL report a node's bandwidth only when it first gains
> > + * memory, so recompute the weights whenever N_MEMORY changes.
> > + */
> > + wi_state_refresh();
>
> If the function fails, should we at least pr_warn_once() ?
>
The only failure state is -ENOMEM, wasn't sure that was worth warning
on. I actually debated whether to just make this a void function.
I don't have a strong feeling here, but happy to add a warn if you
prefer it.
~Gregory
next prev parent reply other threads:[~2026-10-26 15:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-24 17:04 Gregory Price (Meta)
2026-10-26 11:19 ` David Hildenbrand (Arm)
2026-10-26 15:47 ` Gregory Price [this message]
2026-10-26 18:13 ` Joshua Hahn
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=at91WFlW96PH-a8A@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=honggyu.kim@sk.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rakie.kim@sk.com \
--cc=stable@vger.kernel.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®