On Wed, Jul 10, 2013 at 04:54:12PM +0530, Raghavendra K T wrote: > >>Ingo, Gleb, > >> > >> From the results perspective, Andrew Theurer, Vinod's test results are > >>pro-pvspinlock. > >>Could you please help me to know what will make it a mergeable > >>candidate?. > >> > >I need to spend more time reviewing it :) The problem with PV interfaces > >is that they are easy to add but hard to get rid of if better solution > >(HW or otherwise) appears. > > Infact Avi had acked the whole V8 series, but delayed for seeing how > PLE improvement would affect it. > I see that Ingo was happy with it too. > The only addition from that series has been > 1. tuning the SPIN_THRESHOLD to 32k (from 2k) > and > 2. the halt handler now calls vcpu_on_spin to take the advantage of > PLE improvements. (this can also go as an independent patch into > kvm) > > The rationale for making SPIN_THERSHOLD 32k needs big explanation. > Before PLE improvements, as you know, > kvm undercommit scenario was very worse in ple enabled cases. > (compared to ple disabled cases). > pvspinlock patches behaved equally bad in undercommit. Both had > similar reason so at the end there was no degradation w.r.t base. > > The reason for bad performance in PLE case was unneeded vcpu > iteration in ple handler resulting in high yield_to calls and double > run queue locks. > With pvspinlock applied, same villain role was played by excessive > halt exits. > > But after ple handler improved, we needed to throttle unnecessary halts > in undercommit for pvspinlock to be on par with 1x result. > Make sense. I will review it ASAP. BTW the latest version is V10 right? -- Gleb. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
