> NB: Tony has seen odd behavior when stress-testing injected > machine checks with this series applied. I suspect that > it's a bug in something else, possibly his BIOS. Bugs in > this series shouldn't be ruled out, though.
v3 did 3.5x better than earlier ones ... survived overnight but died at 91724 injection/consumption/recovery cycles just now. Different symptom, instead of losing some cpus, there was a fatal machine check (PCC=1 and OVER=1 bits set in the machine check bank). This might be from a known issue. Not sure if this was due to some improvement in the code, or because I changed the system configuration by pulling out all the memory except for that on memory controller 0 on node 0. Our BIOS team had told me they'd seen some instability in the injection code on fully populated systems. I did instrument the synchronization in mce_start(). I was a bit worried that with ever increasing numbers of cpus the 100ns delay between pounding on atomic ops on mce_callin might not be enough. But it seems we are not in trouble yet. Slowest synchronization recorded took 1.8M TSC cycles. Mean is 500K cycles. So my gut feeling that the one second timeout was very conservative is correct. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
