On Sat, Nov 17, 2007 at 05:43:33AM +1030, David Newall wrote: > There are a couple of points I would make about your python test harness. > Your program compares real+system jiffies for both cpus; an ideal result > would be 1.00. The measurement is taken over a relatively short period of > approximately a half-second, and you kill the CPU hogs before taking final > measurements, even wait for them to die first. You repeat this > measurement, starting and killing CPU hogs each time. Why do you do that?
The Python test harness is fairly artificial, but this is just the best way I found to reliably reproduce the problem in a short amount of time. It was just for convenience while running git-bisect. When running the C program directly, there seems to be a somewhat random chance that it will start up in the "bad" state. Once the single CPU is stuck in this mostly-idle mode, it seems to stay that way for a while. > What happens if you start the hogs and take the baseline outside of the > loop? The problem still occurs then, but killing/restarting the test app seems to trigger the problem more reliably. As I said in the original email about this, left to its own devices this problem will occur seemingly-randomly. In the original VMware code I observed this problem in, the same process would flip between the "good" and "bad" states seemingly randomly, every few seconds. Thanks, --Micah - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
