Scheduler Priority Cleanup

[Gedare Bloom]

On Mon, May 19, 2014 at 2:19 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 2014-05-16 19:48, Joel Sherrill wrote:
>>
>> Hi
>>
>> In reviewing the _Thread_Change_priority and associated
>> changes in anticipation of using them as a pattern for the
>> set affinity code, I have spotted a few things:
>>
>> + _Scheduler_Update() is only called from _Thread_Change_priority()
>> and _Thread_Set_priority().  It should be renamed to reflect priority.
>> This would change _Scheduler_Update() to _Scheduler_Update_priority()
>> as well as the associated Scheduler_Context element and implementations
>> since they should be renamed.
>
>
> Yes, this sounds good.
>
+1

>
>>
>> + The change_priority, update(_priority), and priority_compare
>> entries in Scheduler_Context are not next to each other. They
>> are also not consistent in naming. They need to be at least
>> reordered.
>>
>> Comments?
>>
>>
>
> The scheduler operations should be reordered to increase cache efficiency,
> e.g. operations used frequently or are critical should move to the begin of
> the structure to be next to the context pointer.
>
I agree. The operations table grew naturally as new functions were
added. Ordering based on some profiling about which operations get
called most often/together is good. I suspect change_priority and
update_priority are infrequent, but priority_compare may be common.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel