Re: Real-Time Preemption, comparison to 2.6.10-mm1

From: K.R. Foley
Date: Thu Jan 06 2005 - 20:12:30 EST


Mark_H_Johnson@xxxxxxxxxxxx wrote:
Do you have a simple way of triggering and trapping the starvation? That
of course is probably asking for a lot. :)


What I have been doing is now recorded as bug #3997 at
http://bugme.osdl.org/show_bug.cgi?id=3997
Running latencytest has the advantage of generating some charts
that I can show others how well (or poorly) the system runs.

I just rebooted in SMP and did a few other tests with the following
steps that should be simpler to set up and run.

[1] Create cpu_test.c as follows:

#define LOOPS 100000000
int main() {
int u, v, k, l;
for (v=0; v<100; v++) {
for (u=0; u<LOOPS; u++) {
k += 1;
if (!(u%100)) {
l += 1;
k = 0;
}
}
}
return k;
}

On my 866 Mhz Pentium III, it runs for about 3 minutes, 45 seconds.
Adjust the outer loop in the code if you need to run shorter or
longer. I would not run more than 5 minutes - you should easily
get the symptom before then. This also puts a limit of how long
you have to wait if the system gets "stuck" and does not respond
to your keyboard or mouse.

[2] Build the application
gcc -o cpu_test cpu_test.c

[3] On a two CPU system (or repeat this step N-1 times for
your N cpu system). Run in a separate window...
chrt -f 10 ./cpu_test

[4] In a separate window...
nice ./cpu_test

At this point, you should have the system 100% utilized with N-1
real time applications & 1 nice application. I used top to confirm
this result.

[5] In a separate window do one or more of the following:
a. head -c $1 /dev/zero >tmpfile
(replacing $1 with about 1.5x your physical memory size
- this is my "disk write" test)
b. cp tmpfile tmpfile2
(this is my "disk copy" test)
c. cat tmpfile tmpfile2 >/dev/null
(this is my "disk read" test)
delete the files when done.

It appears (at least on my system) that disk I/O triggers the
problem more than the other tests (x11perf, top [with no delay]).

I was however in an odd situation [just before I sent this message]
where it appeared that the disk copy was OK but I could not
type on any of my windows - mouse entries were OK but not the
keyboard. That may be a different variant of my "starvation
problem".

--Mark



I have been able to reproduce this on my system. Actually I can pretty much put the system to sleep, at least to all external input/output, for a period of time. I haven't had time to look into this further but will try to later tonight.

kr
-
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/