RE: [ECOS] Round robin scheduler question

[Ian Gilmour <ian dot gilmour at ffei dot co dot uk>]

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew.lunn@ascom.ch]
> Sent: Wednesday, August 20, 2003 12:38 PM
> To: Ian Gilmour
> Cc: Ecos-Discuss (E-mail)
> Subject: Re: [ECOS] 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. 
> 

Personally I'd say no rather than yes. But I can live with the fact that it
may be a matter of system requirements.

Certainly the RTOS's I've most experience with (VRTX) would have task
swapped to TaskC on return from TaskD. And as I'm currently attempting to
port some code from a VRTX environment to an ECOS one I've hit the problem.

> 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
> 

I think you meant NNN >= 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.
> 

Any pointers as to what to change to achieve this would be much appreciated.

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

I think I favour option 2.


>    Andrew
> 


Thanks for the prompt reply Andrew.


cheers,


Ian

(And apologies for the rubbish below - I have no control over it!)

----------------------------------------------------------------------------
CONFIDENTIALITY AND DISCLAIMER NOTICE

This message and any attachment is confidential and is protected by
copyright. If you are not the intended recipient, please email the sender or
telephone +44 (0)1442 213440 and delete this message and any attachment from
your system. Dissemination and or copying of this email is prohibited if you
are not the intended recipient.

We believe, but do not warrant, that this email and any attachments are
virus free. You should take full responsibility for virus checking.

No responsibility is accepted by FUJIFILM Electronic Imaging Limited for
personal emails or emails unconnected with FUJIFILM Electronic Imaging
Limited's business.
----------------------------------------------------------------------------

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