On Wed, Nov 12, 2008 at 08:03:49AM -0800, Paul E. McKenney wrote: > On Wed, Nov 12, 2008 at 10:05:08AM +0100, Heiko Carstens wrote: > > On Tue, Nov 11, 2008 at 09:34:51AM -0800, Paul E. McKenney wrote: > > > > Were you using preemptible RCU earlier as well? Raphael was using > > > > classic RCU. Don't get me wrong, all problems need fixing, just trying > > > > to make sure I understand where the problems are occurring. > > > > Indeed, my fault. I just try to reproduce a cpu hotplug bug with classic RCU > > and cpu hotplug stress test, but no luck so far. > > OK, then my next step will be to send Rafael an updated version of > my hierarchical RCU, which is more robust than classic RCU against > online/offline stress tests. On the machines I have access to, anyway. ;-) > > Then I will look at preemptable RCU, which undoubtably needs some of the > same help that I have been giving to hierarchical RCU. Manfred thus > wins the clairvoyance award! Well, I tried all day long to reproduce a cpu hotplug/stop_machine hang with classic RCU and a kernel configuration that is as close as possible to Raphael's configuration, but it just continues to work without a bug. One of the machines is a virtual machine with 8 virtual cpus mapped on two real cpus. The real cpus are again shared with other guests. So I end up with cpu steal times of 50-90%. That should have revealed races in the stop_machine code, considering that thousands of cpu hotplug operations happened. I let these test machines running over night. Maybe something happens... but at a first glance it looks more like the reworked stop_machine code triggers a different bug that already is present. Hmmm... -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
