On Mon, Jul 22, 2013 at 01:51:52PM +0100, Christoffer Dall wrote: > On 22 July 2013 10:53, Raghavendra KT <raghavendra.kt.linux@xxxxxxxxx> wrote: > > On Fri, Jul 19, 2013 at 7:23 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > >> So far, when a guest executes WFE (like when waiting for a spinlock > >> to become unlocked), we don't do a thing and let it run uninterrupted. > >> > >> Another option is to trap a blocking WFE and offer the opportunity > >> to the scheduler to switch to another task, potentially giving the > >> vcpu holding the spinlock a chance to run sooner. > >> > > > > Idea looks to be correct from my experiments on x86. It does bring some > > percentage of benefits in overcommitted guests. Infact, > > > > https://lkml.org/lkml/2013/7/22/41 tries to do the same thing for x86. > > (this results in using ple handler heuristics in vcpu_block pach). > > What about the adverse effect in the non-overcommitted case? Could we not detect overcommitment and only set the TWE bit in this case (per VCPU scheduled to run)? The advantage of a properly para-virtualised lock is that you can target which VCPU to wake up. I don't think we can do this currently (without assumptions about the underlying OS and how the compiler allocates registers in the ticket spinlocks). There have been suggestions to use WFE in user-space for a more power efficient busy loop (usually in user-only locking, I think some PostreSQL does that) together with an automatic even stream for waking up the WFE (Sudeep posted some patches recently for enabling 100us event stream). If such feature gets used, we have a new meaning for WFE and we may not want to trap it all the time. Question for Will - do we have a PMU counter for WFE? (don't ask why ;)) -- Catalin -- 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
