theo.borm

choppyness when running double_precision_optimized_matmult_d demo

Discussion created by theo.borm on Jul 25, 2008
Latest reply on Jul 25, 2008 by MicahVillmow
symptom of blocking io in Xorg or fglrx kernel module?

I Tried three things:

./double_precision_optimized_matmult_d -q -t -x 512 -i 10000
Time: 62.741000s
Gflops: 39.84635

./double_precision_optimized_matmult_d -q -t -x 1024 -i 1000
Time: 49.943000s
Gflops: 40.04565

./double_precision_optimized_matmult_d -q -t -x 2048 -i 100
Time: 44.449000s
Gflops: 35.99631

All reasonable results, though a tad short of what I imagine should be possible with the hardware.

First is not a problem, second results in the system freezing for ~1 second every ~7 seconds (choppy), third results in the system freezing for ~10 seconds every ~11 second (unusable)

looking at processor usage I see that 1 (of 4) cores gets ~ 100% utilization by the matmult_d program (reasonable because it's not a multithreaded app), and that (especially noticeable in the second case) the freezing glitches coincide with a drop in utilization of the cpu running matmult_d, and a jump (to 100%) of the utilization of the cpu running Xorg. Also I see that often Xorg and matmult_d "swap cores".

This pattern suggests to me that matmult_d is doing something that causes it to block waiting for Xorg, and then Xorg does something that is (seemingly) not interruptible. My first hunches are either something bus/DMA related or something kernel space related (perhaps spending too long in the fglrx kernel module with interrupts turned off?).

Would this be a correct assesment of the situation, and does this mean that it is up to the application programmer alone to maintain responsiveness of the system? If this is the case I am a bit woried about the potential consequences for system stability of using the proprietary fglrx driver. (Of course it could be Xorg's problem, but I'm not used to this kind of behaviour - but then again, I'm no Xguru).

Regards,

Theo

Outcomes