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,
Srinivasulu Thanneeru <sthanneeru.opensrc@micron.com>
Subject: Re: [PATCH v4 3/3] mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving
Date: Wed, 31 Jan 2024 11:35:53 -0500 [thread overview]
Message-ID: <Zbp26WZBkzhpLTLV@memverge.com> (raw)
In-Reply-To: <87y1c5g8qw.fsf@yhuang6-desk2.ccr.corp.intel.com>
On Wed, Jan 31, 2024 at 05:19:51PM +0800, Huang, Ying wrote:
> Gregory Price <gregory.price@memverge.com> writes:
>
> > On Wed, Jan 31, 2024 at 02:43:12PM +0800, Huang, Ying wrote:
> >> Gregory Price <gourry.memverge@gmail.com> writes:
> >> >
> >> > +static unsigned int weighted_interleave_nodes(struct mempolicy *policy)
> >> > +{
> >> > + unsigned int node = current->il_prev;
> >> > +
> >> > + if (!current->il_weight || !node_isset(node, policy->nodes)) {
> >> > + node = next_node_in(node, policy->nodes);
> >> > + /* can only happen if nodemask is being rebound */
> >> > + if (node == MAX_NUMNODES)
> >> > + return node;
> >>
> >> I feel a little unsafe to read policy->nodes at same time of writing in
> >> rebound. Is it better to use a seqlock to guarantee its consistency?
> >> It's unnecessary to be a part of this series though.
> >>
> >
> > I think this is handled already? It is definitely an explicit race
> > condition that is documented elsewhere:
> >
> > /*
> > * mpol_rebind_policy - Migrate a policy to a different set of nodes
> > *
> > * Per-vma policies are protected by mmap_lock. Allocations using per-task
> > * policies are protected by task->mems_allowed_seq to prevent a premature
> > * OOM/allocation failure due to parallel nodemask modification.
> > */
>
> Thanks for pointing this out!
>
> If we use task->mems_allowed_seq reader side in
> weighted_interleave_nodes() we can guarantee the consistency of
> policy->nodes. That may be not deserved, because it's not a big deal to
> allocate 1 page in a wrong node.
>
> It makes more sense to do that in
> alloc_pages_bulk_array_weighted_interleave(), because a lot of pages may
> be allocated there.
>
That's probably worth just adding now, I'll do it and squash the style
updates into the branch. Sorry Andrew, I guess 1 last version is
inbound :]
I'll pick up the reviewed tags along the way.
~Gregory
next prev parent reply other threads:[~2024-01-31 16:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 18:20 [PATCH v4 0/3] mm/mempolicy: weighted interleave mempolicy and sysfs extension Gregory Price
2024-01-30 18:20 ` [PATCH v4 1/3] mm/mempolicy: implement the sysfs-based weighted_interleave interface Gregory Price
2024-01-30 18:20 ` [PATCH v4 2/3] mm/mempolicy: refactor a read-once mechanism into a function for re-use Gregory Price
2024-01-30 18:20 ` [PATCH v4 3/3] mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving Gregory Price
2024-01-31 5:12 ` Gregory Price
2024-01-31 6:43 ` Huang, Ying
2024-01-31 7:43 ` Gregory Price
2024-01-31 9:19 ` Huang, Ying
2024-01-31 16:35 ` Gregory Price [this message]
2024-01-31 17:29 ` Gregory Price
2024-02-01 1:55 ` Huang, Ying
2024-02-01 2:01 ` Gregory Price
2024-02-01 2:18 ` Gregory Price
2024-02-01 3:02 ` Huang, Ying
2024-02-01 3:10 ` 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=Zbp26WZBkzhpLTLV@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.opensrc@micron.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.