search for: cpu_yield_lowlatency

On Fri, Oct 21, 2016 at 01:58:55PM +0200, Christian Borntraeger wrote: > stop_machine can take a very long time if the hypervisor does > overcommitment for guest CPUs. When waiting for "the one", lets > give up our CPU by using the new cpu_relax_yield. This seems something that would apply to most other virt stuff. Lets Cc a few more lists for that. > Signed-off-by:

On Fri, Oct 21, 2016 at 01:58:55PM +0200, Christian Borntraeger wrote: > stop_machine can take a very long time if the hypervisor does > overcommitment for guest CPUs. When waiting for "the one", lets > give up our CPU by using the new cpu_relax_yield. This seems something that would apply to most other virt stuff. Lets Cc a few more lists for that. > Signed-off-by:

...*/ > > - cpu_relax(); > > + cpu_relax_yield(); > > if (msdata->state != curstate) { > > curstate = msdata->state; > > switch (curstate) { > > -- > > 2.5.5 > > This is the only caller of cpu_relax_yield()? As a step to removing cpu_yield_lowlatency this series is nice so I have no objection. But "general" kernel coders still have basically no chance of using this properly. I wonder what can be done about that. I've got that spin_do/while series I'll rebase on top of this, but a spin_yield variant of them is of no more help...

...ere this makes sense in the future, but I expect that we have much less places for yield than we need for lowlatency. PS: We do something similar for our arch implementation for spinlocks, but there we use the directed yield as we know which CPU holds the lock. > > As a step to removing cpu_yield_lowlatency this series is nice so I > have no objection. But "general" kernel coders still have basically > no chance of using this properly. > > I wonder what can be done about that. I've got that spin_do/while > series I'll rebase on top of this, but a spin_yield variant of...