From: Gregory Price <gregory.price@memverge.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: Gregory Price <gourry.memverge@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org, corbet@lwn.net,
akpm@linux-foundation.org, honggyu.kim@sk.com, rakie.kim@sk.com,
hyeongtak.ji@sk.com, mhocko@kernel.org, vtavarespetr@micron.com,
jgroves@micron.com, ravis.opensrc@micron.com,
sthanneeru@micron.com, emirakhur@micron.com, Hasan.Maruf@amd.com,
seungjun.ha@samsung.com, hannes@cmpxchg.org,
dan.j.williams@intel.com
Subject: Re: [PATCH v3 4/4] mm/mempolicy: change cur_il_weight to atomic and carry the node with it
Date: Fri, 26 Jan 2024 11:38:01 -0500 [thread overview]
Message-ID: <ZbPf6d2cQykdl3Eb@memverge.com> (raw)
In-Reply-To: <87sf2klez8.fsf@yhuang6-desk2.ccr.corp.intel.com>
On Fri, Jan 26, 2024 at 03:40:27PM +0800, Huang, Ying wrote:
> Gregory Price <gourry.memverge@gmail.com> writes:
>
> > Two special observations:
> > - if the weight is non-zero, cur_il_weight must *always* have a
> > valid node number, e.g. it cannot be NUMA_NO_NODE (-1).
>
> IIUC, we don't need that, "MAX_NUMNODES-1" is used instead.
>
Correct, I just thought it pertinent to call this out explicitly since
I'm stealing the top byte, but the node value has traditionally been a
full integer.
This may be relevant should anyone try to carry, a random node value
into this field. For example, if someone tried to copy policy->home_node
into cur_il_weight for whatever reason.
It's worth breaking out a function to defend against this - plus to hide
the bit operations directly as you recommend below.
> > /* Weighted interleave settings */
> > - u8 cur_il_weight;
> > + atomic_t cur_il_weight;
>
> If we use this field for node and weight, why not change the field name?
> For example, cur_wil_node_weight.
>
ack.
> > + if (cweight & 0xFF)
> > + *policy = cweight >> 8;
>
> Please define some helper functions or macros instead of operate on bits
> directly.
>
ack.
> > else
> > *policy = next_node_in(current->il_prev,
> > pol->nodes);
>
> If we record current node in pol->cur_il_weight, why do we still need
> curren->il_prev. Can we only use pol->cur_il_weight? And if so, we can
> even make current->il_prev a union.
>
I just realized that there's a problem here for shared memory policies.
from weighted_interleave_nodes, I do this:
cur_weight = atomic_read(&policy->cur_il_weight);
...
weight--;
...
atomic_set(&policy->cur_il_weight, cur_weight);
On a shared memory policy, this is a race condition.
I don't think we can combine il_prev and cur_wil_node_weight because
the task policy may be different than the current policy.
i.e. it's totally valid to do the following:
1) set_mempolicy(MPOL_INTERLEAVE)
2) mbind(..., MPOL_WEIGHTED_INTERLEAVE)
Using current->il_prev between these two policies, is just plain incorrect,
so I will need to rethink this, and the existing code will need to be
updated such that weighted_interleave does not use current->il_prev.
~Gregory
next prev parent reply other threads:[~2024-01-26 16:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-25 18:43 [PATCH v3 0/4] mm/mempolicy: weighted interleave mempolicy and sysfs extension Gregory Price
2024-01-25 18:43 ` [PATCH v3 1/4] mm/mempolicy: implement the sysfs-based weighted_interleave interface Gregory Price
2024-01-25 18:43 ` [PATCH v3 2/4] mm/mempolicy: refactor a read-once mechanism into a function for re-use Gregory Price
2024-01-25 18:43 ` [PATCH v3 3/4] mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving Gregory Price
2024-01-26 7:10 ` Huang, Ying
2024-01-26 15:57 ` Gregory Price
2024-01-25 18:43 ` [PATCH v3 4/4] mm/mempolicy: change cur_il_weight to atomic and carry the node with it Gregory Price
2024-01-26 7:40 ` Huang, Ying
2024-01-26 16:38 ` Gregory Price [this message]
2024-01-29 8:17 ` Huang, Ying
2024-01-29 15:48 ` Gregory Price
2024-01-29 18:11 ` Gregory Price
2024-01-30 3:15 ` Huang, Ying
2024-01-30 3:33 ` Gregory Price
2024-01-30 5:18 ` Huang, Ying
2024-01-30 16:01 ` Gregory Price
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=ZbPf6d2cQykdl3Eb@memverge.com \
--to=gregory.price@memverge.com \
--cc=Hasan.Maruf@amd.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=emirakhur@micron.com \
--cc=gourry.memverge@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=honggyu.kim@sk.com \
--cc=hyeongtak.ji@sk.com \
--cc=jgroves@micron.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=rakie.kim@sk.com \
--cc=ravis.opensrc@micron.com \
--cc=seungjun.ha@samsung.com \
--cc=sthanneeru@micron.com \
--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.