[Bug 1647] Modular SuperCore Scheduler

[bugzilla-daemon at rtems.org]

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

--- Comment #25 from Gedare <giddyup44 at yahoo.com> 2010-08-26 16:01:45 CDT ---
(In reply to comment #24)
> Created an attachment (id=1032)
 --> (https://www.rtems.org/bugzilla/attachment.cgi?id=1032) [details]
> Tmtests output on sis after applying patch
> 
> This is the output of the tmtests after applying the patch.  A couple of cases
> had significant increases:
> 
> < rtems_task_wake_after: yield -- returns to caller 25
> < rtems_task_wake_after: yields -- preempts caller 89
> ---
> > rtems_task_wake_after: yield -- returns to caller 36
> > rtems_task_wake_after: yields -- preempts caller 95
> 
> So deciding nothing has to be done got worse (a lot).  This shows up a lot like
> below:
> 
> 24,26c24,26
> < rtems_task_restart: ready task -- preempts caller 121
> < rtems_semaphore_release: task readied -- returns to caller 49
> < rtems_task_create 246
> ---
> > rtems_task_restart: ready task -- preempts caller 124
> > rtems_semaphore_release: task readied -- returns to caller 60
> > rtems_task_create 267
> 
> The preempt case is slower but not much.  The returns to caller (e.g. no
> dispatch needed) is MUCH slower.  Ditto for task create.
> 
> I am thinking there much be a much fuller evaluation of what to do now than
> there was.  What happened?

I think too much flexibility was built-in. I would say that accessing the
scheduling data structures now takes an extra 2 function calls via the function
pointers.  I'm sure this is where the added overhead comes from.  We can
probably cut this down to 1 function call by hard-wiring the ready queue based
on the scheduler implementation.

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