Re: RT task scheduling

[Vernon Mauery <vernux@us.ibm.com>]

On Friday 07 April 2006 20:01, Steven Rostedt wrote:
> Hi Bill,
>
> I'm just catching up on this thread.  Is your main concern that a High
> prio task is going to be unnecessary delayed because there's a lower RT
> task on the same CPU and time is needed to push it off to another CPU?
> It's late, so forgive me if this is a stupid question ;)

What I have gathered from this thread is that there are two important (and 
partially conflicting) requirements for better real-time support.

1) Deterministic scheduling algorithms (SWSRPS).  Basically, with uniprocessor 
systems (or smp with a global run queue), it was really easy to say, run the 
highest priority task in the queue.  But when there are several queues that 
are independent of each other, it is difficult.  According to SWSRPS, nr_cpus 
highest priority runnable tasks should _always_ be running (regardless of 
which queue they are on).  This might mean that there are longer latencies a) 
to determine the nr_cpus highest priority tasks and b) because of cache 
issues.

2) Maximum deterministic latency.  A task should be able to say that if it 
relinquishes the processor for now, MAX_LATENCY nanoseconds (or ticks or 
whatever you want to measure time in) later, it will be back in time to meet 
a deadline.

As I understand it, real time is all about determinism.  But there are several 
places where we have to focus on determinism to make it all behave as it 
should.

Priority A > B > C
If a lower priority task C gets run just because it is the highest in that 
CPU's run queue while there is a higher priority task B is sleeping while A 
runs (on a 2 proc system), this is WRONG.  But then again, we need to make 
sure that we can determine the maximum latency to preempt C to run B and try 
to minimize that.

Poof!  More smoke in the air.  I hope that clears it up.

--Vernon

> On Fri, 2006-04-07 at 16:36 -0700, Bill Huey wrote:
> > > Has this cleared some things up?  If not, let me know what else needs
> > > clarification.
> >
> > Yes, but you should really work to clarify terminology. Is this better ?
>
> Goes both ways :)
>
> -- Steve
>
> PS. It's really good to see you back on LKML.  I've missed your posts.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/