From: Mel Gorman <mgorman@techsingularity.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>,
Davidlohr Bueso <dave@stgolabs.net>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: Loadavg accounting error on arm64
Date: Mon, 16 Nov 2020 16:42:32 +0000 [thread overview]
Message-ID: <20201116164232.GT3371@techsingularity.net> (raw)
In-Reply-To: <20201116152946.GR3371@techsingularity.net>
On Mon, Nov 16, 2020 at 03:29:46PM +0000, Mel Gorman wrote:
> I did, it was the on_cpu ordering for the blocking case that had me
> looking at the smp_store_release and smp_cond_load_acquire in arm64 in
> the first place thinking that something in there must be breaking the
> on_cpu ordering. I'm re-reading it every so often while trying to figure
> out where the gap is or whether I'm imagining things.
>
> Not fully tested but did not instantly break either
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index d2003a7d5ab5..877eaeba45ac 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4459,14 +4459,26 @@ static void __sched notrace __schedule(bool preempt)
> if (signal_pending_state(prev_state, prev)) {
> prev->state = TASK_RUNNING;
> } else {
> - prev->sched_contributes_to_load =
> + int acct_load =
> (prev_state & TASK_UNINTERRUPTIBLE) &&
> !(prev_state & TASK_NOLOAD) &&
> !(prev->flags & PF_FROZEN);
>
> - if (prev->sched_contributes_to_load)
> + prev->sched_contributes_to_load = acct_load;
> + if (acct_load) {
> rq->nr_uninterruptible++;
>
> + /*
> + * Pairs with p->on_cpu ordering, either a
> + * smp_load_acquire or smp_cond_load_acquire
> + * in the ttwu path before ttwu_do_activate
> + * p->sched_contributes_to_load. It's only
> + * after the nr_interruptible update happens
> + * that the ordering is critical.
> + */
> + smp_wmb();
> + }
> +
> /*
> * __schedule() ttwu()
> * prev_state = prev->state; if (p->on_rq && ...)
>
This passed the test. Load averages taken once a minute after the test
completed showed
950.21 977.17 990.69 1/853 2117
349.00 799.32 928.69 1/859 2439
128.18 653.85 870.56 1/861 2736
47.08 534.84 816.08 1/860 3029
17.29 437.50 765.00 1/865 3357
6.35 357.87 717.13 1/865 3653
2.33 292.74 672.24 1/861 3709
0.85 239.46 630.17 1/859 3711
0.31 195.87 590.73 1/857 3713
0.11 160.22 553.76 1/853 3715
With 5.10-rc3, it got stuck with a load average of 244 after the test
completed even though the machine was idle.
--
Mel Gorman
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@techsingularity.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: Loadavg accounting error on arm64
Date: Mon, 16 Nov 2020 16:42:32 +0000 [thread overview]
Message-ID: <20201116164232.GT3371@techsingularity.net> (raw)
In-Reply-To: <20201116152946.GR3371@techsingularity.net>
On Mon, Nov 16, 2020 at 03:29:46PM +0000, Mel Gorman wrote:
> I did, it was the on_cpu ordering for the blocking case that had me
> looking at the smp_store_release and smp_cond_load_acquire in arm64 in
> the first place thinking that something in there must be breaking the
> on_cpu ordering. I'm re-reading it every so often while trying to figure
> out where the gap is or whether I'm imagining things.
>
> Not fully tested but did not instantly break either
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index d2003a7d5ab5..877eaeba45ac 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4459,14 +4459,26 @@ static void __sched notrace __schedule(bool preempt)
> if (signal_pending_state(prev_state, prev)) {
> prev->state = TASK_RUNNING;
> } else {
> - prev->sched_contributes_to_load =
> + int acct_load =
> (prev_state & TASK_UNINTERRUPTIBLE) &&
> !(prev_state & TASK_NOLOAD) &&
> !(prev->flags & PF_FROZEN);
>
> - if (prev->sched_contributes_to_load)
> + prev->sched_contributes_to_load = acct_load;
> + if (acct_load) {
> rq->nr_uninterruptible++;
>
> + /*
> + * Pairs with p->on_cpu ordering, either a
> + * smp_load_acquire or smp_cond_load_acquire
> + * in the ttwu path before ttwu_do_activate
> + * p->sched_contributes_to_load. It's only
> + * after the nr_interruptible update happens
> + * that the ordering is critical.
> + */
> + smp_wmb();
> + }
> +
> /*
> * __schedule() ttwu()
> * prev_state = prev->state; if (p->on_rq && ...)
>
This passed the test. Load averages taken once a minute after the test
completed showed
950.21 977.17 990.69 1/853 2117
349.00 799.32 928.69 1/859 2439
128.18 653.85 870.56 1/861 2736
47.08 534.84 816.08 1/860 3029
17.29 437.50 765.00 1/865 3357
6.35 357.87 717.13 1/865 3653
2.33 292.74 672.24 1/861 3709
0.85 239.46 630.17 1/859 3711
0.31 195.87 590.73 1/857 3713
0.11 160.22 553.76 1/853 3715
With 5.10-rc3, it got stuck with a load average of 244 after the test
completed even though the machine was idle.
--
Mel Gorman
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-16 16:43 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-16 9:10 Loadavg accounting error on arm64 Mel Gorman
2020-11-16 9:10 ` Mel Gorman
2020-11-16 11:49 ` Mel Gorman
2020-11-16 11:49 ` Mel Gorman
2020-11-16 12:00 ` Mel Gorman
2020-11-16 12:00 ` Mel Gorman
2020-11-16 12:53 ` Peter Zijlstra
2020-11-16 12:53 ` Peter Zijlstra
2020-11-16 12:58 ` Peter Zijlstra
2020-11-16 12:58 ` Peter Zijlstra
2020-11-16 15:29 ` Mel Gorman
2020-11-16 15:29 ` Mel Gorman
2020-11-16 16:42 ` Mel Gorman [this message]
2020-11-16 16:42 ` Mel Gorman
2020-11-16 16:49 ` Peter Zijlstra
2020-11-16 16:49 ` Peter Zijlstra
2020-11-16 17:24 ` Mel Gorman
2020-11-16 17:24 ` Mel Gorman
2020-11-16 17:41 ` Will Deacon
2020-11-16 17:41 ` Will Deacon
2020-11-16 12:46 ` Peter Zijlstra
2020-11-16 12:46 ` Peter Zijlstra
2020-11-16 12:58 ` Mel Gorman
2020-11-16 12:58 ` Mel Gorman
2020-11-16 13:11 ` Will Deacon
2020-11-16 13:11 ` Will Deacon
2020-11-16 13:37 ` Mel Gorman
2020-11-16 13:37 ` Mel Gorman
2020-11-16 14:20 ` Peter Zijlstra
2020-11-16 14:20 ` Peter Zijlstra
2020-11-16 15:52 ` Mel Gorman
2020-11-16 15:52 ` Mel Gorman
2020-11-16 16:54 ` Peter Zijlstra
2020-11-16 16:54 ` Peter Zijlstra
2020-11-16 17:16 ` Mel Gorman
2020-11-16 17:16 ` Mel Gorman
2020-11-16 19:31 ` Mel Gorman
2020-11-16 19:31 ` Mel Gorman
2020-11-17 8:30 ` [PATCH] sched: Fix data-race in wakeup Peter Zijlstra
2020-11-17 8:30 ` Peter Zijlstra
2020-11-17 9:15 ` Will Deacon
2020-11-17 9:15 ` Will Deacon
2020-11-17 9:29 ` Peter Zijlstra
2020-11-17 9:29 ` Peter Zijlstra
2020-11-17 9:46 ` Peter Zijlstra
2020-11-17 9:46 ` Peter Zijlstra
2020-11-17 10:36 ` Will Deacon
2020-11-17 10:36 ` Will Deacon
2020-11-17 12:52 ` Valentin Schneider
2020-11-17 12:52 ` Valentin Schneider
2020-11-17 15:37 ` Valentin Schneider
2020-11-17 15:37 ` Valentin Schneider
2020-11-17 16:13 ` Peter Zijlstra
2020-11-17 16:13 ` Peter Zijlstra
2020-11-17 19:32 ` Valentin Schneider
2020-11-17 19:32 ` Valentin Schneider
2020-11-18 8:05 ` Peter Zijlstra
2020-11-18 8:05 ` Peter Zijlstra
2020-11-18 9:51 ` Valentin Schneider
2020-11-18 9:51 ` Valentin Schneider
2020-11-18 13:33 ` Marco Elver
2020-11-18 13:33 ` Marco Elver
2020-11-17 9:38 ` [PATCH] sched: Fix rq->nr_iowait ordering Peter Zijlstra
2020-11-17 9:38 ` Peter Zijlstra
2020-11-17 11:43 ` Mel Gorman
2020-11-17 11:43 ` Mel Gorman
2020-11-19 9:55 ` [tip: sched/urgent] " tip-bot2 for Peter Zijlstra
2020-11-17 12:40 ` [PATCH] sched: Fix data-race in wakeup Mel Gorman
2020-11-17 12:40 ` Mel Gorman
2020-11-19 9:55 ` [tip: sched/urgent] " tip-bot2 for Peter Zijlstra
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=20201116164232.GT3371@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=dave@stgolabs.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=will@kernel.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.