search for: spin_do

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:

...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 to the caller. What makes this unique? Long latency and not performance critical? Most places where we spin and maybe yield have been moved to arch code, but I wonder whether we can make an easier to u...

...now 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 them > is of no more help to the caller. > > What makes this unique? Long latency and not performance critical? I think what makes this unique is that ALL cpus spin and wait for one. It was really the only plac...