lkml.org 
[lkml]   [2002]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Problem with the O(1) scheduler in 2.4.19
On Tue, 3 Sep 2002, Ingo Molnar wrote:

> does -10 make it equivalent to the 2.4 behavior? Could you somehow measure
> the priority where it's still acceptable? Ie. -8 or -9?

I've done some more experimenting, and I've found something interesting.
I've attached two very simple CPU hog programs.

The program latency runs in a tight loop calling gettimeofday, and prints
the loop time if it exceeds 8 ms. This program simulates a game server,
video decoding program or whatever.

The program hog sleeps for five seconds, and then runs in a tight loop.
This program simulates a cron job. This program is always run at the
default nice level (0).

I will now run the latency program at the three different nice levels -20
(high prio), 0 (normal) and 20 (low prio). A few seconds after latency is
started, hog is started. Note that there are no visible latency when hog
program is started, the latency comes from the loop five seconds after
the start:

[root@boris Prog]# nice -n -20 ./latency
00:22:16: dt = 608.864 ms
00:22:17: dt = 150.978 ms
00:22:18: dt = 150.983 ms
00:22:19: dt = 150.979 ms
00:22:20: dt = 150.981 ms

[root@boris Prog]# nice -n 0 ./latency
00:22:49: dt = 604.865 ms
00:22:50: dt = 150.966 ms
00:22:50: dt = 150.964 ms
00:22:51: dt = 150.963 ms
00:22:51: dt = 152.981 ms

[root@boris Prog]# nice -n 19 ./latency
00:23:44: dt = 678.848 ms
00:23:44: dt = 150.964 ms
00:23:44: dt = 150.978 ms
00:23:44: dt = 150.978 ms
00:23:45: dt = 150.978 ms

Here we can see that the time slice for hog is stabilized at 150 ms, and
that as the latency program is niced, the hog program gets its time slices
more often. I think this is what's supposed to happen, but the problem is
the >600 ms timeslice that hog gets when it starts to run. Comments?

One could also argue that 150 ms is a bit too much. For video playback at
25 FPS, that means three lost frames. I do understand the benefits of
long timeslices, of course. It's a hard choice...

This is on a HZ=1000 2.4.19+sched-2.4.19-rc2-A4 kernel.

/Tobias
#include <unistd.h>
int main()
{
sleep(5);
for (;;)
;
}
#include <stdio.h>
#include <sys/time.h>
#include <time.h>
#include <unistd.h>

double now(void)
{
struct timeval t;
gettimeofday(&t, NULL);
return t.tv_sec + t.tv_usec * 1e-6;
}

int main()
{
double t0, t, dt, max_dt = 0.0;
char tbuf[100];
time_t utc;

t0 = now();
for (;;)
{
t = now();
dt = t - t0;
if (dt > 0.008)
{
max_dt = dt;
time(&utc);
strftime(tbuf, sizeof(tbuf), "%T", localtime(&utc));
printf("%s: dt = %.3f ms\n", tbuf, max_dt * 1e3);
t = now();
}
t0 = t;
}

return 0;
}
\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.093 / U:7.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site