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 v2 3/3] mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving
Date: Tue, 23 Jan 2024 16:27:35 -0500 [thread overview]
Message-ID: <ZbAvR+U+tyLvsh8R@memverge.com> (raw)
In-Reply-To: <87a5owv454.fsf@yhuang6-desk2.ccr.corp.intel.com>
On Tue, Jan 23, 2024 at 04:35:19PM +0800, Huang, Ying wrote:
> Gregory Price <gregory.price@memverge.com> writes:
>
> > On Mon, Jan 22, 2024 at 11:54:34PM -0500, Gregory Price wrote:
> >> >
> >> > Can the above code be simplified as something like below?
> >> >
> >> > resume_node = prev_node;
> > --- resume_weight = 0;
> > +++ resume_weight = weights[node];
> >> > for (...) {
> >> > ...
> >> > }
> >> >
> >>
> >> I'll take another look at it, but this logic is annoying because of the
> >> corner case: me->il_prev can be NUMA_NO_NODE or an actual numa node.
> >>
> >
> > After a quick look, as long as no one objects to (me->il_prev) remaining
> > NUMA_NO_NODE
>
> MAX_NUMNODES-1 ?
>
When setting a new policy, the il_prev gets set to NUMA_NO_NODE. It's
not harmful and is just (-1), which is functionally the same as
(MAX_NUMNODES-1) for the purpose of iterating the nodemask with
next_node_in(). So it's fine to set (resume_node = me->il_prev)
as discussed.
I have a cleaned up function I'll push when i fix up a few other spots.
> > while having a weight assigned to pol->wil.cur_weight,
>
> I think that it is OK.
>
> And, IIUC, pol->wil.cur_weight can be 0, as in
> weighted_interleave_nodes(), if it's 0, it will be assigned to default
> weight for the node.
>
cur_weight is different than the global weights. cur_weight tells us
how many pages are remaining to allocate for the current node.
(cur_weight = 0) can happen in two scenarios:
- initial setting of mempolicy (NUMA_NO_NODE w/ cur_weight=0)
- weighted_interleave_nodes decrements it down to 0
Now that i'm looking at it - the second condition should not exist, and
we can eliminate it. The logic in weighted_interleave_nodes is actually
annoyingly unclear at the moment, so I'm going to re-factor it a bit to
be more explicit.
~Gregory
next prev parent reply other threads:[~2024-01-23 21:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 17:57 [PATCH v2 0/3] mm/mempolicy: weighted interleave mempolicy and sysfs extension Gregory Price
2024-01-19 17:57 ` [PATCH v2 1/3] mm/mempolicy: implement the sysfs-based weighted_interleave interface Gregory Price
2024-01-22 8:03 ` Huang, Ying
2024-01-22 16:58 ` Gregory Price
2024-01-19 17:57 ` [PATCH v2 2/3] mm/mempolicy: refactor a read-once mechanism into a function for re-use Gregory Price
2024-01-19 17:57 ` [PATCH v2 3/3] mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving Gregory Price
2024-01-23 3:02 ` Huang, Ying
2024-01-23 4:54 ` Gregory Price
2024-01-23 5:16 ` Gregory Price
2024-01-23 8:35 ` Huang, Ying
2024-01-23 21:27 ` Gregory Price [this message]
2024-01-24 1:51 ` Huang, Ying
2024-01-24 18:01 ` Gregory Price
2024-01-23 8:13 ` Huang, Ying
2024-01-23 8:40 ` Huang, Ying
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=ZbAvR+U+tyLvsh8R@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.