> 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 Yes, after we changed to synchronize_srcu_expedited, grace period latency improves much and overall this is good. However as I mentioned in another mail, in our setting-IRQ-affinity and ping test, we can still see some impact of KVM_SET_GSI_ROUTING ioctl. I wrote another patch in that mail and want to be examined to see if it is acceptable or has any problem, thank you. Best regards, -Gonglei -- 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
