From: Peter Zijlstra <peterz@infradead.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, Kirill Tkhai <tkhai@yandex.ru>,
Kirill Tkhai <ktkhai@virtuozzo.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"juri.lelli@redhat.com" <juri.lelli@redhat.com>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
"dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>,
"bsegall@google.com" <bsegall@google.com>,
"mgorman@suse.de" <mgorman@suse.de>,
Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC][PATCH 1/4] sched: Force the address order of each sched class descriptor
Date: Fri, 20 Dec 2019 11:00:33 +0100 [thread overview]
Message-ID: <20191220100033.GE2844@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <0a957e8d-7af8-613c-11ae-f51b9b241eb7@rasmusvillemoes.dk>
On Fri, Dec 20, 2019 at 09:52:37AM +0100, Rasmus Villemoes wrote:
> On 19/12/2019 22.44, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> >
> > In order to make a micro optimization in pick_next_task(), the order of the
> > sched class descriptor address must be in the same order as their priority
> > to each other. That is:
> >
> > &idle_sched_class < &fair_sched_class < &rt_sched_class <
> > &dl_sched_class < &stop_sched_class
> >
> > In order to guarantee this order of the sched class descriptors, add each
> > one into their own data section and force the order in the linker script.
>
> I think it would make the code simpler if one reverses these, see other
> reply.
I started out agreeing, because of that mess around STOP_SCHED_CLASS and
that horrid BEFORE_CRUD thing.
Then, when I fixed it all up, I saw what it did to Kyrill's patch (#4)
and that ends up looking like:
- if (likely((prev->sched_class == &idle_sched_class ||
- prev->sched_class == &fair_sched_class) &&
+ if (likely(prev->sched_class >= &fair_sched_class &&
And that's just weird.
Then I had a better look and now...
> > +/*
> > + * The order of the sched class addresses are important, as they are
> > + * used to determine the order of the priority of each sched class in
> > + * relation to each other.
> > + */
> > +#define SCHED_DATA \
> > + *(__idle_sched_class) \
> > + *(__fair_sched_class) \
> > + *(__rt_sched_class) \
> > + *(__dl_sched_class) \
> > + STOP_SCHED_CLASS
I'm confused, why does that STOP_SCHED_CLASS need magic here at all?
Doesn't the linker deal with empty sections already by making them 0
sized?
> > /*
> > * Align to a 32 byte boundary equal to the
> > * alignment gcc 4.5 uses for a struct
> > @@ -308,6 +326,7 @@
> > #define DATA_DATA \
> > *(.xiptext) \
> > *(DATA_MAIN) \
> > + SCHED_DATA \
> > *(.ref.data) \
>
> Doesn't this make the structs end up in .data (writable) rather than
> .rodata?
Right! That wants fixing.
next prev parent reply other threads:[~2019-12-20 10:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-19 21:44 [RFC][PATCH 0/4] sched: Optimizations to sched_class processing Steven Rostedt
2019-12-19 21:44 ` [RFC][PATCH 1/4] sched: Force the address order of each sched class descriptor Steven Rostedt
2019-12-20 8:52 ` Rasmus Villemoes
2019-12-20 10:00 ` Peter Zijlstra [this message]
2019-12-20 10:12 ` Rasmus Villemoes
2019-12-20 10:44 ` Kirill Tkhai
2019-12-20 15:18 ` Steven Rostedt
2019-12-20 12:19 ` Peter Zijlstra
2019-12-20 14:34 ` Rasmus Villemoes
2019-12-19 21:44 ` [RFC][PATCH 2/4] sched: Have sched_class_highest define by vmlinux.lds.h Steven Rostedt
2019-12-20 8:52 ` Rasmus Villemoes
2020-06-25 11:53 ` [tip: sched/core] " tip-bot2 for Steven Rostedt (VMware)
2019-12-19 21:44 ` [RFC][PATCH 3/4] sched: Remove struct sched_class next field Steven Rostedt
2019-12-20 12:14 ` Rasmus Villemoes
2020-06-25 11:53 ` [tip: sched/core] sched: Remove struct sched_class::next field tip-bot2 for Steven Rostedt (VMware)
2019-12-19 21:44 ` [RFC][PATCH 4/4] sched: Micro optimization in pick_next_task() and in check_preempt_curr() Steven Rostedt
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=20191220100033.GE2844@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=ktkhai@virtuozzo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tkhai@yandex.ru \
--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).