On 09/27/2012 01:26 PM, Raghavendra K T wrote: > On 09/27/2012 02:20 PM, Avi Kivity wrote: >> On 09/25/2012 04:43 PM, Jiannan Ouyang wrote: >>> I've actually implemented this preempted_bitmap idea. >> >> Interesting, please share the code if you can. >> >>> However, I'm doing this to expose this information to the guest, so the >>> guest is able to know if the lock holder is preempted or not before >>> spining. Right now, I'm doing experiment to show that this idea works. >>> >>> I'm wondering what do you guys think of the relationship between the >>> pv_ticketlock approach and PLE handler approach. Are we going to adopt >>> PLE instead of the pv ticketlock, and why? >> >> Right now we're searching for the best solution. The tradeoffs are more >> or less: >> >> PLE: >> - works for unmodified / non-Linux guests >> - works for all types of spins (e.g. smp_call_function*()) >> - utilizes an existing hardware interface (PAUSE instruction) so likely >> more robust compared to a software interface >> >> PV: >> - has more information, so it can perform better > > Should we also consider that we always have an edge here for non-PLE > machine? True. The deployment share for these is decreasing rapidly though. I hate optimizing for obsolete hardware. -- error compiling committee.c: too many arguments to function -- 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
