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 - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
