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
> >> >> + 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.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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel