Scheduler Priority Cleanup

[Joel Sherrill]

On 5/19/2014 9:33 AM, Gedare Bloom wrote:
> 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
OK. Added to the wish/TODO list.
>>> + 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.
That would be my guess.

The order is very far from cache optimized with the initialize first (called
only once and tick near the bottom. :)

I would guess that block, unblock, tick, and priority_compare are the most
frequent. That would be my 4 for the 16 byte cache line.

The next 4 are up for discussion. 
>> --
>> 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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985