On Thu, Sep 24, 2009 at 10:28:41AM -0700, Paul E. McKenney wrote: > > Paul, > > > > There is a scenario where this path, which updates KVM memory slots, is > > called relatively often. > > > > Each synchronize_srcu() call takes about 10ms (avg 3ms per > > synchronize_sched call), so this is hurting us. > > > > Is this expected? Is there any possibility for synchronize_srcu() > > optimization? > > > > There are other sides we can work on, such as reducing the memory slot > > updates, but i'm wondering what can be done regarding SRCU itself. > > This is expected behavior, but there is a possible fix currently > in mainline (Linus's git tree). The idea would be to create a > synchronize_srcu_expedited(), which starts with synchronize_srcu(), and > replaces the synchronize_sched() calls with synchronize_sched_expedited(). > > This could potentially reduce the overall synchronize_srcu() latency > to well under a microsecond. The price to be paid is that each instance > of synchronize_sched_expedited() IPIs all the online CPUs, and awakens > the migration thread on each. > > Would this approach likely work for you? Hum, this path can be triggered by a guest, so IPI'ing all online CPUs is not a happy thought. -- 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
