* 2.6.0 SCHED_RR/SCHED_FIFO strangness .
@ 2004-01-14 7:45 Der Herr Hofrat
2004-01-15 9:26 ` Andrew Morton
0 siblings, 1 reply; 3+ messages in thread
From: Der Herr Hofrat @ 2004-01-14 7:45 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: 2.6.0 SCHED_RR/SCHED_FIFO strangness .
2004-01-15 9:26 ` Andrew Morton
@ 2004-01-14 19:42 ` Der Herr Hofrat
0 siblings, 0 replies; 3+ messages in thread
From: Der Herr Hofrat @ 2004-01-14 19:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Der Herr Hofrat, linux-kernel
> Der Herr Hofrat <der.herr@hofr.at> wrote:
> >
> > 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 ?
>
> Can you send us the entire test app?
>
The system I'm running on is IDE based NN 2.6.0 without any patches :
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(tm) XP 2400+
stepping : 1
cpu MHz : 2002.899
to run this the tsc scaller needs to be taken from /proc/cpuinfo and passed
as an argument - to get microsecond resolution for SCHED_FIFO/SCHED_RR
comparison on this system I used
./sched_jitter -s 2002
to load the box a bit run
while : ; do find / > /dev/null 2>&1 ; done &
results from 5 runs atached below the code.
note that in all runs SCHED_FIFO shows low jitter and then rare events of
very high delay - to catch this reliably one needs to run quite long loops.
Even with much longer loops I could not get these high values for SCHED_RR
the average cases for SCHED_FIFO are better though.
hofrat
---sched_jitter.c---
#include <stdio.h>
#include <stdlib.h>
#include <sched.h>
#include <string.h>
#include <limits.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <asm/io.h>
void usage(void);
__inline__ unsigned long long int hwtime(void)
{
unsigned long long int x;
__asm__ __volatile__("rdtsc\n\t"
:"=A" (x));
return x;
}
void usage(void)
{
printf("usage: sched_jitter -s tsc_scaler\n");
}
#define GRAPH_SIZE 1000
int main(int argc, char **argv)
{
int i;
char *optstr = "hs:";
char c;
unsigned long long graph[3][GRAPH_SIZE];
unsigned long long hwtime1,hwtime2,jitt;
unsigned long long jitt_max[3];
unsigned long scale = 1;
unsigned long policy;
unsigned long long n,loops;
struct sched_param param;
while ( (c = getopt(argc, argv, optstr)) != -1 ) {
switch (c) {
case 's': /* tsc scaling factor */
scale = strtol( optarg, NULL, 0);
break;
case 'h': /* verbose */
usage();
exit(0);
default:
fprintf(stderr,"time: Unknown option \'-%c\', exitting.\n", c);
fprintf(stderr," use \'time -h\' for help\n");
exit(1);
}
}
/* from linux/include/sched.h
* #define SCHED_NORMAL 0
* #define SCHED_FIFO 1
* #define SCHED_RR 2
*/
memset(graph,0,sizeof(graph));
/* just run with SCHED_FIFO and then SCHED_RR */
for(policy=1;policy<3;policy++){
param.sched_priority = sched_get_priority_max(policy);
// param.sched_priority = sched_get_priority_min(policy);
if(sched_setscheduler(getpid(),policy,¶m)){
printf("sched_setscheduler failed - exiting\n");
exit(-1);
}
jitt_max[policy]=0LL;
n=0LL;
loops=1000000000LL;
while(n < loops){
unsigned long long index=0;
hwtime2 = hwtime();
hwtime1 = hwtime();
jitt=hwtime1-hwtime2;
index=jitt/scale;
if(index > GRAPH_SIZE){
printf("out of bounds value\n");
} else {
graph[policy][index] += 1;
}
if(jitt > jitt_max[policy]){
jitt_max[policy]=jitt;
}
n++;
}
}
/* dump data */
for(policy=0;policy<3;policy++){
if(jitt_max[policy]/scale < GRAPH_SIZE){
printf("\nworst case delay in run with policy %ld = %lld us\n",
policy,
jitt_max[policy]/scale);
} else {
printf("\nworst case delay in run with policy %ld = %lld us out of bounds - results are unreliable !\n",
policy,
jitt_max[policy]/scale);
}
printf("\n");
for(i=0;i<GRAPH_SIZE ;i++){
if(graph[policy][i])
printf("%4d us: %16lld \n",i,graph[policy][i]);
}
}
return 0;
}
output from 5 runs while running a endless find / loop to produce some load.
worst case delay in run with policy 1 = 207 us
0 us: 999990261
1 us: 195
2 us: 9473
3 us: 50
4 us: 3
5 us: 11
6 us: 2
12 us: 2
15 us: 1
19 us: 1
207 us: 1
worst case delay in run with policy 2 = 18 us
0 us: 999990347
1 us: 178
2 us: 9360
3 us: 104
4 us: 5
6 us: 1
11 us: 1
12 us: 1
13 us: 2
18 us: 1
worst case delay in run with policy 1 = 84 us
0 us: 999990512
1 us: 155
2 us: 9239
3 us: 90
13 us: 1
15 us: 1
16 us: 1
84 us: 1
worst case delay in run with policy 2 = 16 us
0 us: 999991063
1 us: 167
2 us: 8668
3 us: 89
4 us: 4
6 us: 1
12 us: 2
13 us: 2
14 us: 1
15 us: 2
16 us: 1
worst case delay in run with policy 1 = 156 us
0 us: 999990506
1 us: 153
2 us: 9246
3 us: 86
4 us: 1
13 us: 4
15 us: 1
156 us: 3
worst case delay in run with policy 2 = 31 us
0 us: 999990810
1 us: 134
2 us: 8930
3 us: 105
5 us: 15
6 us: 1
11 us: 1
13 us: 2
14 us: 1
31 us: 1
worst case delay in run with policy 1 = 168 us
0 us: 999990419
1 us: 163
2 us: 9313
3 us: 96
4 us: 6
5 us: 1
13 us: 1
168 us: 1
worst case delay in run with policy 2 = 18 us
0 us: 999990337
1 us: 168
2 us: 9405
3 us: 82
4 us: 6
11 us: 1
18 us: 1
worst case delay in run with policy 1 = 81 us
0 us: 999990481
1 us: 145
2 us: 9292
3 us: 74
4 us: 3
6 us: 1
13 us: 1
14 us: 1
18 us: 1
81 us: 1
worst case delay in run with policy 2 = 16 us
0 us: 999990391
1 us: 217
2 us: 9313
3 us: 73
11 us: 2
12 us: 1
13 us: 1
15 us: 1
16 us: 1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: 2.6.0 SCHED_RR/SCHED_FIFO strangness .
2004-01-14 7:45 2.6.0 SCHED_RR/SCHED_FIFO strangness Der Herr Hofrat
@ 2004-01-15 9:26 ` Andrew Morton
2004-01-14 19:42 ` Der Herr Hofrat
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2004-01-15 9:26 UTC (permalink / raw)
To: Der Herr Hofrat; +Cc: linux-kernel
Der Herr Hofrat <der.herr@hofr.at> wrote:
>
> 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 ?
Can you send us the entire test app?
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-01-15 19:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-14 7:45 2.6.0 SCHED_RR/SCHED_FIFO strangness Der Herr Hofrat
2004-01-15 9:26 ` Andrew Morton
2004-01-14 19:42 ` Der Herr Hofrat
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®