These functions are used only via the function pointers in the generic
SMP scheduler implementation. Provide them as static inline so that the
compiler can optimize more easily.
This scheduler attempts to account for needed thread migrations caused
as a side-effect of a thread state, affinity, or priority change operation.
This scheduler has its own allocate_processor handler named
_Scheduler_SMP_Allocate_processor_exact() because
_Scheduler_SMP_Allocate_processor() attempts to prevent an executing
thread from moving off its current CPU without considering affinity.
Without this, the scheduler makes all the right decisions and then
they are discarded at the end.
==Side Effects of Adding This Scheduler==
Added Thread_Control * parameter to Scheduler_SMP_Get_highest_ready type
so methods looking for the highest ready thread can filter by the processor
on which the thread blocking resides. This allows affinity to be considered.
Simple Priority SMP and Priority SMP ignore this parameter.
+ Added get_lowest_scheduled argument to _Scheduler_SMP_Enqueue_ordered().
+ Added allocate_processor argument to the following methods:
- _Scheduler_SMP_Block()
- _Scheduler_SMP_Enqueue_scheduled_ordered()
- _Scheduler_SMP_Enqueue_scheduled_ordered()
+ schedulerprioritysmpimpl.h is a new file with prototypes for methods
which were formerly static in schedulerprioritysmp.c but now need to
be public to be shared with this scheduler.
NOTE:
_Scheduler_SMP_Get_lowest_ready() appears to have a path which would
allow it to return a NULL. Previously, _Scheduler_SMP_Enqueue_ordered()
would have asserted on it. If it cannot return a NULL,
_Scheduler_SMP_Get_lowest_ready() should have an assertions.
When trying to compile RTEMS for the Stellaris LM3S6965 board, I had an
issue of pppd.exe's .rodata section being too big to fit in the board's
memory image (region 'ROM_INT' overflowed).
This reverts commit d9ff8b3e68.
It is not that simple:
https://sourceware.org/ml/binutils/2014-06/msg00062.html
On Fri, Jun 06, 2014 at 01:31:48PM +0200, Sebastian Huber wrote:
> On 2014-06-06 13:23, Sebastian Huber wrote:
> >Ok, so this "cmplwi cr0, rX, ppc_exc_lock_std@sdarel" is illegal,
> >since
> >ppc_exc_lock_std@sdarel is signed and the immediate is unsigned
> >16-bit? The
> >assembler doesn't issue a warning about this.
> >
> >Exists there a way to rescue this cmplwi hack without relaxing the
> >overflow
> >checks?
>
> Hm, sorry, it was surprisingly simple. This works:
>
> "cmplwi cr0, rX, ppc_exc_lock_std@sdarel@l"
>
> I was not aware that you can add several @ in a row.
That is the wrong thing to use here. sdarel@l translates to a VLE
reloc which applies to a split 16-bit field in VLE insns.
You want
cmpwi cr0, rX, ppc_exc_lock_std@sdarel
to properly compare a 16-bit signed number from sym@sdarel.
Note that the assembler does error if you write something like
cmplwi 3,-30000
or
cmpwi 3,40000
so what the linker is now doing is extending this behaviour to link
time.
See also
https://sourceware.org/ml/binutils/2014-06/msg00059.html
On Fri, Jun 06, 2014 at 11:01:10AM +0200, Sebastian Huber wrote:
> I performed a git bisect and found this:
>
> 93d1b056cb396d6468781fe0e40dd769891bed32 is the first bad commit
> commit 93d1b056cb396d6468781fe0e40dd769891bed32
> Author: Alan Modra <amodra@gmail.com>
> Date: Tue May 20 11:42:42 2014 +0930
>
> Rewrite ppc32 backend .sdata and .sdata2 handling
Hmm, I'm surprised that your git bisect found this patch. Was
_SDA_BASE_ set differently before this?
> 0x00000000000dfc00 _SDA_BASE_
> 0x00000000000d7f78 ppc_exc_lock_std
> 4b8: 28 05 00 00 cmplwi r5,0
> 4ba: R_PPC_SDAREL16 ppc_exc_lock_std
ppc_exc_lock_std@sdarel will be calculating 0xd7f78 - 0xdfc00
which is 0xf...fff8378, and that falls foul of
commit 86c9573369616e7437481b6e5533aef3a435cdcf
Author: Alan Modra <amodra@gmail.com>
Date: Sat Mar 8 13:05:06 2014 +1030
Better overflow checking for powerpc32 relocations
cmplwi has an *unsigned* 16-bit field, and we now check the overflow
properly.
I wonder how many more of these we'll hit, and whether the uproar will
be enough that I'll be forced to relax the checks?
The nanoseconds extension returned wrong values on secondary processors
since some of the global timer registeres are banked. Use global
variables instead.
Check that the executing thread is not NULL in _Scheduler_Tick(). It
may be NULL in case the processor has an optional scheduler assigned and
the system was not able to start the processor.
Remove rtems_current_shell_env as this is dangerous because
the env can be NULL if used outside of a valid shell with the
POSIX key to an env set up.
Clean up the usage of rtems_current_shell_env.
Rename _Scheduler_Update() to _Scheduler_Update_priority(). Add
parameter for the new thread priority to avoid direct usage of
Thread_Control::current_priority in the scheduler operation.
Replace _Scheduler_Allocate() with _Scheduler_Node_initialize(). Remove
the return status and thus the node initialization must be always
successful.
Rename _Scheduler_Free() to _Scheduler_Node_destroy().
Guest systems in paravirtualization environments run usually in user
mode. Thus it is not possible to directly access the PSR and TBR
registers. Use functions instead of inline assembler to access these
registers if RTEMS_PARAVIRT is defined.
Sebastian Huber
Joel Sherrill
Martin Galvan
Martin Boretto
Daniel Hellstrom
Chris Johns
Christian Mauderer