On Mon, 2011-05-30 at 12:40 +0300, Pekka Enberg wrote: > Hi Sasha, > > On Mon, May 30, 2011 at 12:34 PM, Sasha Levin <levinsasha928@xxxxxxxxx> wrote: > > It would mean we need that many VCPUs: current br_read_lock() doesn't > > really do anything, which means that running these tests with dummy > > threads won't work. > > Heh, sure they're doing something - they're burning CPU. You assume > that br_write_unlock() will actually resume all of them but I'd really > like to see a reproducible test case for that. ;-) I agree with what you're saying: testing whether br_write_lock() makes all VCPU threads stop and br_write_unlock() makes all VCPU threads resume should be tested. I'm just saying that we're limited to as many VCPU threads as we can create. br_read_lock() won't do anything on a non-VCPU thread, which makes it impossible to test it on non-VCPUs. > Do you think it's a bad idea? I don't quite see why - as I've said > before, this is something we learned the hard way when we implemented > our own locking primitives and stop-the-world for Jato. Those are just > so damn easy to break accidentally so having some safety net is > definitely worth it. > > Also, didn't Paul suggest some debugging magic to detect errors? > > Pekka -- Sasha. -- 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
