Re: Scheduling behaviour of 23-rc4-rt1 on my intel centrino Duo.

[Darren Hart <dvhltc@us.ibm.com>]

On Thursday 04 October 2007 23:40:53 Girish kathalagiri wrote:
> Hi Daren,
>
> > 1) How are you determining which CPUs these threads spend their time on?
>
> The hourglass test's  stores the execution trace . The trace is
> generated as the threads are run , each time the thread detects a gap
> in the execution, it records a trace , which includes start time and
> end time of the continuous block of  CPU time that a thread received.
>   output looks something like this
> tracerec: 3 4569.581302 4669.572704 99.991402 400.007546
> tracerec: 1 4669.581304 4769.572370 99.991066 400.007679
> tracerec: 2 4769.581030 4869.572168 99.991138 400.007727
> tracerec: 4 4869.580624 4969.571912 99.991288 400.007546
>  (columns: thread id , strat time and end time of gap free time of
> CPU, duration of the interval, last column shows the time it has taken
> from the end of the previous schedule of the thread)
> The values are plotted and the graph is attached.
> It can be noted that the thread 0 runs all the time and the thread 1-5
> gets time equal slices. Hence it can be seen that thread 0 is hogging
> a cpu completely and thread 1-5 are hogging the other cpu.

OK, looking at your output, I'd have to agree (although your plot doesn't show 
thread 0 running at all, I presume it should have a gray bar that is a full 
10 seconds long?).

I usually deal with SCHED_FIFO threads, so I'm going to take a look at the 
SCHED_RR behavior to see how it's implemented.

--Darren

>
> > 2) RTHIGH doesn't do anything for us.  What is the value of the
> > SCHED_FIFO priority those threads run at?  Is it the same for every one?
>
> All the threads are running at an RT priority of 97 (maxrt prio - 2).
> code:
>
>  max_realtime_pri = sched_get_priority_max (SCHED_RR);
>
> and
>
> case RTHIGH:
>     param->sched_priority = max_realtime_pri - 2;
>
> > Note that depending on exactly what those threads do (I am unfamiliar
> > with the hourglass testcase) it isn't unreasonable for them to all run on
> > the same CPU if their runnable/sleeping states happen to line up just
> > right.  It is also very possible that they bounce around from CPU to CPU
> > in rapid succession if the runnable/sleeping windows overlap in exactly
> > the wrong way :-)
>
> All the thread does is it hogs the CPU whenever it can.I have also
> attached the test result and the graph that has run for 10s. Graph
> basically shows the context switches that has happened between the
> thread 1-5 (round robin).Thread 0 does not record any context switch
> as it runs fully
> thread 0 recorded 10.039664 seconds (99.999746 %)



-- 
Darren Hart
IBM Linux Technology Center
Realtime Linux Team