From: Peter Zijlstra <peterz@infradead.org>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Patrick Bellasi <patrick.bellasi@arm.com>,
Mel Gorman <mgorman@techsingularity.net>,
Vincent Guittot <vincent.guittot@linaro.org>,
Ingo Molnar <mingo@kernel.org>,
Norbert Manthey <nmanthey@amazon.de>,
Frederic Weisbecker <frederic@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64
Date: Wed, 4 Apr 2018 09:25:13 +0200 [thread overview]
Message-ID: <20180404072513.GF4082@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F7B3C2F5D@ORSMSX110.amr.corp.intel.com>
On Wed, Apr 04, 2018 at 12:04:00AM +0000, Luck, Tony wrote:
> > bisect says:
> >
> > d519329f72a6 ("sched/fair: Update util_est only on util_avg updates")
> >
> > Reverting just this commit makes the problem go away.
>
> The unaligned read and write seem to come from:
>
> struct util_est ue = READ_ONCE(p->se.avg.util_est);
> WRITE_ONCE(p->se.avg.util_est, ue);
>
> which is puzzling as they were around before. Also the "avg"
> field is tagged with an attribute to make it cache aligned
> and there don't look to be holes in the structure that would
> make util_est not be 8-byte aligned ... though it does consist
> of two 4-byte fields, so legal for it to be 4-byte aligned.
Right, I remember being careful with that. Which again brings me to the
RANDSTRUCT thing, which will mess that up.
Does the below cure things? It makes absolutely no difference for my
x86_64-defconfig build, but it puts more explicit alignment constraints
on things.
diff --git a/include/linux/sched.h b/include/linux/sched.h
index f228c6033832..b3d697f3b573 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -300,7 +300,7 @@ struct util_est {
unsigned int enqueued;
unsigned int ewma;
#define UTIL_EST_WEIGHT_SHIFT 2
-};
+} __attribute__((__aligned__(sizeof(u64))));
/*
* The load_avg/util_avg accumulates an infinite geometric series
@@ -364,7 +364,7 @@ struct sched_avg {
unsigned long runnable_load_avg;
unsigned long util_avg;
struct util_est util_est;
-};
+} ____cacheline_aligned;
struct sched_statistics {
#ifdef CONFIG_SCHEDSTATS
@@ -435,7 +435,7 @@ struct sched_entity {
* Put into separate cache line so it does not
* collide with read-mostly values above.
*/
- struct sched_avg avg ____cacheline_aligned_in_smp;
+ struct sched_avg avg;
#endif
};
next prev parent reply other threads:[~2018-04-04 7:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-02 23:24 v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64 Luck, Tony
2018-04-02 23:39 ` Luck, Tony
2018-04-03 7:37 ` Peter Zijlstra
2018-04-03 18:58 ` Luck, Tony
2018-04-04 0:04 ` Luck, Tony
2018-04-04 7:25 ` Peter Zijlstra [this message]
2018-04-04 16:38 ` Luck, Tony
2018-04-04 16:53 ` Peter Zijlstra
2018-04-05 8:05 ` Peter Zijlstra
2018-04-05 8:56 ` Ingo Molnar
2018-04-05 9:18 ` [tip:sched/urgent] sched/core: Force proper alignment of 'struct util_est' tip-bot 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=20180404072513.GF4082@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@kernel.org \
--cc=nmanthey@amazon.de \
--cc=patrick.bellasi@arm.com \
--cc=tony.luck@intel.com \
--cc=vincent.guittot@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).