From: Mel Gorman <mgorman@techsingularity.net>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: torvalds@linux-foundation.org, tglx@linutronix.de,
mingo@kernel.org, hpa@zytor.com, efault@gmx.de,
linux-kernel@vger.kernel.org, matt@codeblueprint.co.uk,
peterz@infradead.org, ggherdovich@suse.cz,
linux-tip-commits@vger.kernel.org, mpe@ellerman.id.au
Subject: Re: [tip:sched/core] sched/numa: Delay retrying placement for automatic NUMA balance after wake_affine()
Date: Wed, 9 May 2018 09:41:48 +0100 [thread overview]
Message-ID: <20180509084148.qzpsetz74pkg7g33@techsingularity.net> (raw)
In-Reply-To: <20180507110607.GA3828@linux.vnet.ibm.com>
On Mon, May 07, 2018 at 04:06:07AM -0700, Srikar Dronamraju wrote:
> > @@ -1876,7 +1877,18 @@ static void numa_migrate_preferred(struct task_struct *p)
> >
> > /* Periodically retry migrating the task to the preferred node */
> > interval = min(interval, msecs_to_jiffies(p->numa_scan_period) / 16);
> > - p->numa_migrate_retry = jiffies + interval;
> > + numa_migrate_retry = jiffies + interval;
> > +
> > + /*
> > + * Check that the new retry threshold is after the current one. If
> > + * the retry is in the future, it implies that wake_affine has
> > + * temporarily asked NUMA balancing to backoff from placement.
> > + */
> > + if (numa_migrate_retry > p->numa_migrate_retry)
> > + return;
>
> The above check looks wrong. This check will most likely to be true,
> numa_migrate_preferred() itself is called either when jiffies >
> p->numa_migrate_retry or if the task's numa_preferred_nid has changed.
>
Sorry for the delay getting back -- viral infections combined with a public
day off is slowing me.
You're right, without affine wakeups with a wakeup-intensive workload
the path may never be hit and with the current code, it effectively acts
as a broken throttling mechanism. However, I've confirmed that "fixing"
it has mixed results with many regressions on x86 for both 2 and 4 socket
boxes. I need time to think about it and see if this can be fixed without
introducing another regression. I'll also check if a plain revert is the
way to go for a short-term fix and then revisit it.
Thanks Srikar.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2018-05-09 8:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-13 13:37 [PATCH 0/6] Reduce migrations and conflicts with automatic NUMA balancing v2 Mel Gorman
2018-02-13 13:37 ` [PATCH 1/6] sched/fair: Avoid an unnecessary lookup of current CPU ID during wake_affine Mel Gorman
2018-02-21 10:27 ` [tip:sched/core] " tip-bot for Mel Gorman
2018-02-13 13:37 ` [PATCH 2/6] sched/fair: Defer calculation of prev_eff_load in wake_affine until needed Mel Gorman
2018-02-21 10:28 ` [tip:sched/core] sched/fair: Defer calculation of 'prev_eff_load' in wake_affine_weight() " tip-bot for Mel Gorman
2018-02-13 13:37 ` [PATCH 3/6] sched/fair: Do not migrate on wake_affine_weight if weights are equal Mel Gorman
2018-02-21 10:28 ` [tip:sched/core] sched/fair: Do not migrate on wake_affine_weight() " tip-bot for Mel Gorman
2018-02-13 13:37 ` [PATCH 4/6] sched/fair: Do not migrate due to a sync wakeup on exit Mel Gorman
2018-02-21 10:29 ` [tip:sched/core] " tip-bot for Peter Zijlstra
2018-02-13 13:37 ` [PATCH 5/6] sched/fair: Consider SD_NUMA when selecting the most idle group to schedule on Mel Gorman
2018-02-21 10:29 ` [tip:sched/core] " tip-bot for Mel Gorman
2018-02-13 13:37 ` [PATCH 6/6] sched/numa: Delay retrying placement for automatic NUMA balance after wake_affine Mel Gorman
2018-02-13 14:01 ` Peter Zijlstra
2018-02-13 14:18 ` Mel Gorman
2018-02-13 14:43 ` Peter Zijlstra
2018-02-13 15:00 ` Mel Gorman
2018-02-13 15:10 ` Peter Zijlstra
2018-02-21 10:30 ` [tip:sched/core] sched/numa: Delay retrying placement for automatic NUMA balance after wake_affine() tip-bot for Mel Gorman
2018-05-07 11:06 ` Srikar Dronamraju
2018-05-09 8:41 ` Mel Gorman [this message]
2018-05-09 10:58 ` Srikar Dronamraju
2018-05-09 16:34 ` Mel Gorman
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=20180509084148.qzpsetz74pkg7g33@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=efault@gmx.de \
--cc=ggherdovich@suse.cz \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=peterz@infradead.org \
--cc=srikar@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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.