lkml.org 
[lkml]   [2019]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH 1/4] sched: Force the address order of each sched class descriptor
From
Date
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.

> +/*
> + * 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
> +
> /*
> * 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?

Rasmus

\
 
 \ /
  Last update: 2019-12-20 09:53    [W:0.066 / U:4.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site