Avi Kivity wrote: > David S. Ahern wrote: >> I ran another test case with SMT disabled, and while I was at it >> converted TSC delta to operations/sec. The results without SMT are >> confusing -- to me anyways. I'm hoping someone can explain it. >> Basically, using a count of 10,000,000 (per your web page) with SMT >> disabled the guest detected a soft lockup on the CPU. So, I dropped the >> count down to 1,000,000. So, for 1e6 iterations: >> >> without SMT, with EPT: >> HC: 259,455 ops/sec >> PIO: 226,937 ops/sec >> MMIO: 113,180 ops/sec >> >> without SMT, without EPT: >> HC: 274,825 ops/sec >> PIO: 247,910 ops/sec >> MMIO: 111,535 ops/sec >> >> Converting the prior TSC deltas: >> >> with SMT, with EPT: >> HC: 994,655 ops/sec >> PIO: 875,116 ops/sec >> MMIO: 439,738 ops/sec >> >> with SMT, without EPT: >> HC: 994,304 ops/sec >> PIO: 903,057 ops/sec >> MMIO: 423,244 ops/sec >> >> Running the tests repeatedly I did notice a fair variability (as much as >> -10% down from these numbers). >> >> Also, just to make sure I converted the delta to ops/sec, the formula I >> used was cpu_freq / dTSC * count = operations/sec >> >> > > The only think I can think of is cpu frequency scaling lying about the > cpu frequency. Really the test needs to use time and not the time stamp > counter. > > Are the results expressed in cycles/op more reasonable? > Power settings seem to be the root cause. With this HP server the SMT mode must be disabling or overriding a power setting that is enabled in the bios. I found one power-based knob that gets non-SMT performance close to SMT numbers. Not very intuitive that SMT/non-SMT can differ so dramatically. david -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
