[Bug 1647] Modular SuperCore Scheduler

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1647

--- Comment #30 from Joel Sherrill <joel.sherrill at oarcorp.com> 2010-08-29 10:04:47 CDT ---
Do a diff on pre and post-2 and look at the differences.  Some that stand out
to me are:

< rtems_task_delete: blocked task 187
> rtems_task_delete: blocked task 204

< rtems_task_delete: ready task 188
> rtems_task_delete: ready task 205

< rtems_task_set_priority: returns to caller 50
> rtems_task_set_priority: returns to caller 55

< rtems_task_set_priority: preempts caller 114
> rtems_task_set_priority: preempts caller 119

< rtems_message_queue_urgent: task readied -- returns to caller 55
> rtems_message_queue_urgent: task readied -- returns to caller 61

< rtems_message_queue_broadcast: task readied -- returns to caller 71
> rtems_message_queue_broadcast: task readied -- returns to caller 81

On a positive note, some of the times are actually down.  

This is very close.  It looks like a couple of more places where the heir
computation is occurring and there was a short cut before.

FWIW I am doing these runs on sis (sis tm*.exe).  That puts the output in a log
subdirectory.  Then I "cat log/tm* >XXX.txt" Then I diff old new and compare.

You mentioned in am email that you are allocating memory for the scheduler in
the task create.  This is OK just be careful that the scheduler implementation
itself is doing this because if a user provides an external scheduler, we won't
know the size.  Also this needs to be accounted for in confdefs.h calculations
for memory size for each task.

This is very close time wise.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.