On Tue, Jan 12, 2010 at 09:28:15AM +0100, Jan Kiszka wrote: > Paul E. McKenney wrote: > > On Tue, Jan 12, 2010 at 01:23:15AM +0100, Jan Kiszka wrote: > >> Jan Kiszka wrote: > >>> Avi Kivity wrote: > >>>> On 01/11/2010 12:13 PM, Jan Kiszka wrote: > >>>>> BTW, does anybody know how to back-port synchronize_srcu_expedited best? > >>>>> It looked like a simple mapping to synchronize_srcu was not sufficient > >>>>> to achieve the same performance as with the pre-srcu locking (e.g. > >>>>> guest&host stalled during guest's framebuffer setup). > >>>>> > >>>> Isn't it sufficient to backport kernel/srcu.c? I thought no sched.c > >>>> changes were necessary. > >>> Haven't looked yet, but if that's the case, it would indeed be > >>> straightforward. > >> It's far away from being straightforward: synchronize_rcu_expedited is > >> based on synchronize_sched_expedited, introduced to 2.6.32. But that > >> services is hooked deep into the scheduler, fiddling directly with > >> runqueues (which are completely private to sched.c). This path looks > >> like a dead end, specifically when its about supporting ~8 major Linux > >> releases backwards. > >> > >> Paul, we have a problem here on the KVM-for-older-kernels front: We need > >> synchronize_rcu_expedited for acceptable write-side performance (there > >> are certain phases with lots of changes, plain synchronize_rcu just > >> stalls both guest and host for several seconds). Our target kernels > >> (down to 2.6.27, unofficially even 2.6.24) do not have the expedited > >> service. Can you think of a poor man's solution for those kernels? > >> > >> Unfortunately, I don't think there is mechanical patching possible to > >> role-back our srcu use to a rw-sem. But I will check this once again > >> tomorrow. > > > > Would it help if I backported the RCU expedited stuff? Yes, it does > > involve kernel/sched.c, but it is reasonably hands-off. > > > > If this would help, please let me know to which kernel version you need > > the backport. > > Thanks a lot. Mmm, it's probably already sufficient when you tell me if > I'm now on the right tracks: > > The idea behind synchronize_sched_expedited is, instead of waiting for > random task switches on all CPUs, to enforce them. It now just reuses > the migration_thread, locks and request queues from the rqs for this > purpose. So it should have the same effect if we create our own > high-prio srcu_expedited kthreads that include the srcu logic which just > complete() the queued requests of some compat > kvm_synchronize_sched_expedited. Did I get it? Yep. There are any number of ways to force context switches on all CPUs, and pretty much any will work for synchronize_sched_expedited(). Once you have something that does synchronize_sched_expedited(), synchronize_srcu_expedited() can just invoke it. > If so, I will try to write something like this the next days. Will > surely appreciate your review afterwards! Sounds good! Thanx, Paul -- 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
