Messages in this thread | | | From | Der Herr Hofrat <> | Subject | 2.6.0 SCHED_RR/SCHED_FIFO strangness . | Date | Wed, 14 Jan 2004 08:45:07 +0100 (CET) |
| |
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,¶m); // sched_setscheduler(getpid(),SCHED_RR,¶m); ...
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |