lkml.org 
[lkml]   [2004]   [Jan]   [15]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromDer Herr Hofrat <>
Subject2.6.0 SCHED_RR/SCHED_FIFO strangness .
DateWed, 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,&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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:00    [from the cache]
©2003-2008