On 5/19/2014 9:33 AM, Gedare Bloom wrote: > On Mon, May 19, 2014 at 2:19 AM, Sebastian Huber > <sebastian.hu...@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.hu...@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@rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
