All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 29 Jan 2024 22:33:57 -0500	[thread overview]
Message-ID: <ZbhuJTBp68e8eLRv@memverge.com> (raw)
In-Reply-To: <875xzbika0.fsf@yhuang6-desk2.ccr.corp.intel.com>

On Tue, Jan 30, 2024 at 11:15:35AM +0800, Huang, Ying wrote:
> Gregory Price <gregory.price@memverge.com> writes:
> 
> > On Mon, Jan 29, 2024 at 10:48:47AM -0500, Gregory Price wrote:
> >> On Mon, Jan 29, 2024 at 04:17:46PM +0800, Huang, Ying wrote:
> >> > Gregory Price <gregory.price@memverge.com> writes:
> >> > 
> >> > But, in contrast, it's bad to put task-local "current weight" in
> >> > mempolicy.  So, I think that it's better to move cur_il_weight to
> >> > task_struct.  And maybe combine it with current->il_prev.
> >> > 
> >> Style question: is it preferable add an anonymous union into task_struct:
> >> 
> >> union {
> >>     short il_prev;
> >>     atomic_t wil_node_weight;
> >> };
> >> 
> >> Or should I break out that union explicitly in mempolicy.h?
> >> 
> >
> > Having attempted this, it looks like including mempolicy.h into sched.h
> > is a non-starter.  There are build issues likely associated from the
> > nested include of uapi/linux/mempolicy.h
> >
> > So I went ahead and did the following.  Style-wise If it's better to just
> > integrate this as an anonymous union in task_struct, let me know, but it
> > seemed better to add some documentation here.
> >
> > I also added static get/set functions to mempolicy.c to touch these
> > values accordingly.
> >
> > As suggested, I changed things to allow 0-weight in il_prev.node_weight
> > adjusted the logic accordingly. Will be testing this for a day or so
> > before sending out new patches.
> >
> 
> Thanks about this again.  It seems that we don't need to touch
> task->il_prev and task->il_weight during rebinding for weighted
> interleave too.
> 

It's not clear to me this is the case.  cpusets takes the task_lock to
change mems_allowed and rebind task->mempolicy, but I do not see the
task lock access blocking allocations.

Comments from cpusets suggest allocations can happen in parallel.

/*
 * cpuset_change_task_nodemask - change task's mems_allowed and mempolicy
 * @tsk: the task to change
 * @newmems: new nodes that the task will be set
 *
 * We use the mems_allowed_seq seqlock to safely update both tsk->mems_allowed
 * and rebind an eventual tasks' mempolicy. If the task is allocating in
 * parallel, it might temporarily see an empty intersection, which results in
 * a seqlock check and retry before OOM or allocation failure.
 */


For normal interleave, this isn't an issue because it always proceeds to
the next node. The same is not true of weighted interleave, which may
have a hanging weight in task->il_weight.

That is why I looked to combine the two, so at least node/weight were
carried together.

> unsigned int weighted_interleave_nodes(struct mempolicy *policy)
> {
>         unsigned int nid;
>         struct task_struct *me = current;
> 
>         nid = me->il_prev;
>         if (!me->il_weight || !node_isset(nid, policy->nodes)) {
>                 nid = next_node_in(...);
>                 me->il_prev = nid;
>                 me->il_weight = weights[nid];
>         }
>         me->il_weight--;
> 
>         return nid;
> }

I ended up with this:

static unsigned int weighted_interleave_nodes(struct mempolicy *policy)
{
       unsigned int node;
       u8 weight;

       get_wil_prev(&node, &weight);
       /* If nodemask was rebound, just fetch the next node */
       if (!weight) {
               node = next_node_in(node, policy->nodes);
               /* can only happen if nodemask has become invalid */
               if (node == MAX_NUMNODES)
                       return node;
               weight = get_il_weight(node);
       }
       weight--;
       set_wil_prev(node, weight);
       return node;
}

~Gregory

  reply	other threads:[~2024-01-30  3:34 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
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 [this message]
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=ZbhuJTBp68e8eLRv@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.