[Bug 1647] Modular SuperCore Scheduler

[bugzilla-daemon at rtems.org]

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

--- Comment #36 from Gedare <giddyup44 at yahoo.com> 2010-11-12 05:46:28 CST ---
(In reply to comment #35)
> (In reply to comment #34)
> > > Why is this single time higher?  There was no change but we added about 50
> > > instructions.
> > > 
> > > 21c23
> > > < rtems_semaphore_obtain: not available -- caller blocks 700
> > > ---
> > > > rtems_semaphore_obtain: not available -- caller blocks 751
> > 
> > I should have had more coffee before I wrote that. Let me try again.  The above
> > is an example of a case which includes the worst case critical section in
> > RTEMS. It appears that it is ~50 instructions longer.  You have mentioned some
> > overhead due to the indirect calls and loss of some inlining but I am having
> > trouble seeing that account for 50 instructions.  Help me out.
> 
> Inlining the scheduler and ready queue functions saves most of these
> instructions, as I suspected.  The overheads probably are not observed on the
> sparc since function calls are cheap (until the register windows are all used).
> 
> The latency of tm02 is tracking across multiple scheduler calls, so the
> overheads accumulate.
Inlining solely the ready queue functions saves about 30% of the overhead seen
in this test case (cuts down to around 734 cycles). Is this good enough
performance-wise?

Such a change does not really impede the flexibility intended in the modular
scheduler design.  Essentially it means that scheduler implementations must
directly invoke ready queue implementations, which is reasonable to require
IMO.

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