2.6.0 SCHED_RR/SCHED_FIFO strangness .

[Der Herr Hofrat]

Hi !

 doing some simple benchmarks with 2.6.0 I have results I don't
 understand. The setup is a P4 2GHz 2.6.0 kernel running
 Slackware 9.1 with one soft real-time task active only. This one
 task is:

	param.sched_priority = 0;
	sched_setscheduler(getpid(),SCHED_FIFO,&param);
//	sched_setscheduler(getpid(),SCHED_RR,&param);
	...

	while(n < loops) {
                hwtime2 = hwtime();
		hwtime1 = hwtime();
		jitt=hwtime1-hwtime2;
		...
	}

 the jitter is then put into an array using jitt converted to microseconds as
 index. hwtime is:

__inline__ unsigned long long int hwtime(void)
{
        unsigned long long int x;
        __asm__ __volatile__("rdtsc\n\t"
                :"=A" (x));
        return x;
}

 So this should shows how long the task can be interrupted between two 
 consecutive statements (loops is around 1E9).

 The strange thing is that SCHED_FIFO runs always return worse results than
 SCHED_RR runs under even moderate load (one find / in an endless loop, system
 otherwise idle) - any ideas what is causing this ?

 As there is only one task with rt priority in the system I was actually 
 expecting more or less identical worst case results with a slight preference
 for SCHED_FIFO in the average case.

hofrat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/