This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Round robin scheduler question


On Wed, Aug 20, 2003 at 12:05:42PM +0100, Ian Gilmour wrote:
> I'm having problems with round robin scheduling with the multi-level queue
> scheduler so I knocked up a simple test....
> 
> I have a system with a monitor task (TaskA).
> 
> TaskA creates 2 equal priority tasks (TaskB and TaskC) that simply loop,
> each incrementing their own volatile global counter. TaskB and TaskC have
> lower priority than TaskA.
> 
> Task A also creates another high priority task TaskD. TaskD priority is
> lower than TaskA but higher than TaskB and TaskC. TaskD periodically polls
> for Control-C input on the monitor. It polls every NNN clock ticks.
> 
> TaskA periodically (every couple of secs) dumps the contents of the 2 global
> counters until it sees a Control-C flag set by TaskD, at which point it
> kills TaskB, TaskC, and TaskD.
> 
> I have the multi-level queue scheduler enabled and the scheduler timeslicing
> every 5 clock ticks.
> 
> If NNN is greater than or equal to 5 TaskB and TaskC round robin schedule as
> I expect.
> 
> But if NNN is less than 5 TaskC never runs.
> 
> Is this the expected behaviour? Or have I inadvertently set something in the
> ecos config to get this behaviour?
> 
> I expected TaskB and TaskC to get equal time despite neither ever having a
> full 5 clock ticks timeslice.

When TaskB is being rescheduled after being pre-emptied by taskD, it
starts a new time slice quantum. This time slice never completes
because its getting pre-emptied. So no timeslicing is happening.

Does it makes sense to run taskB again after its been preemptied by
the higher priority thread? Probably yes. With any luck its still got
something useful left in the cache so you get a performance gain
compared to running another task. 

Does reseting the timeslice quantum make sense? If you don't reset it,
you need a per thread variable which keeps track of how long the
current thread has left. This adds complexity which in most cases is
not needed.

You have hit a corner case in the scheduler. You either need to

1) Ensure XXX < ticks per time quantum

2) Change the scheduler so that pre-empted threads are put at the tail
   and not the head of the queue and live with the performance
   degradation.

3) Add per thread variable which contains the remaining time slice.

   Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]