Re: Real-Time Preemption, comparison to 2.6.10-mm1
From: K.R. Foley
Date: Wed Jan 05 2005 - 16:22:56 EST
Mark_H_Johnson@xxxxxxxxxxxx wrote:
K.R. Foley wrote:
Mark_H_Johnson@xxxxxxxxxxxx wrote:
[snip - long explanation of how a nice application can starve a non
nice application for minutes at a time on an SMP system]
My point was that -mm definitely has the problem (though to a lesser
degree). The tests I ran showed it on both the disk read and disk copy
stress tests. I guess I should try a vanilla 2.6.10 run as well to see
if it is something introduced in the -mm series (it certainly is not a
recent change...).
I'm curious if anyone is seeing this behavior on UP systems, or is it
only happening on SMP?
The build of 2.6.10 vanilla just completed and I reran my tests with
SMP and with MAXCPUS=1 (UP w/ SMP kernel).
Well that blows one of the theories I was looking at. :( -mm is carrying
a patch that lengthens the cache_hot_time to roughly a ms instead of a
usec, which could effect how fast tasks might be migrated to an idle cpu.
The vanilla 2.6.10 kernel has the non RT starvation problem as well
for both test runs. It looks like this is not something in -mm but a
change between 2.4 and 2.6.
I did notice the test results were a little inconsistent between the
two runs...
2.6.10 SMP 2.6.10 UP (w/ SMP kernel)
disk write starved OK
disk copy OK starved
disk read starved starved
but in both cases, a non nice (non RT) disk application was
starved by a nice (non RT) cpu application for minutes.
Do you have a simple way of triggering and trapping the starvation? That
of course is probably asking for a lot. :)
kr
I wonder who I should be talking to next (or submit a bug report?)
about this.
--Mark
-
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/