On 25/03/14 13:37, Paolo Bonzini wrote: > Il 25/03/2014 04:19, Gonglei (Arei) ha scritto: >> Based on discussions in: >> http://lists.gnu.org/archive/html/qemu-devel/2013-11/threads.html#03322 >> >> About KVM_SET_GSI_ROUTING ioctl, I tested changing RCU to SRCU, but unfortunately >> it looks like SRCU's grace period is no better than RCU. > > Really? This is not what Christian Borntraeger claimed at http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/118083 -- in fact, Andrew Theurer is currently testing a variant of that patch and I was going to post it for 3.16. > > Have you tried synchronize_srcu_expedited? Unlike the RCU variant, you can use this function. On my system I have HZ=100 and lots of CPUs. So RCUs "every cpu has scheduled" is certainly slower than SRCUs algorithm (/* * We use an adaptive strategy for synchronize_srcu() and especially for * synchronize_srcu_expedited(). We spin for a fixed time period * (defined below) to allow SRCU readers to exit their read-side critical * sections. If there are still some readers after 10 microseconds, * we repeatedly block for 1-millisecond time periods. This approach * has done well in testing, so there is no need for a config parameter. */ ) With HZ==1000 and a NO. CPUs small SRCUs spinning might be in the same delay range than classic RCU depending on how long the read side critical section is (if we move from spinning to blocking) So using synchronize_srcu_expedited is certainly something to test as it increased the spinning time. Christian -- 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
