search for: cpu_relax_yield

No need to duplicate the same define everywhere. Since the only user is stop-machine and the only provider is s390, we can use a default implementation of cpu_relax_yield in sched.h. Suggested-by: Russell King <linux at armlinux.org.uk> Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> --- arch/alpha/include/asm/processor.h | 1 - arch/arc/include/asm/processor.h | 3 --- arch/arm/include/asm/processor.h | 2 -- arch/a...

No need to duplicate the same define everywhere. Since the only user is stop-machine and the only provider is s390, we can use a default implementation of cpu_relax_yield in sched.h. Suggested-by: Russell King <linux at armlinux.org.uk> Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> --- arch/alpha/include/asm/processor.h | 1 - arch/arc/include/asm/processor.h | 3 --- arch/arm/include/asm/processor.h | 2 -- arch/a...

...the hypervisor to give up the timeslice. In contrast to the SMT yielding this can result in larger latencies. In some places this latency is unwanted, so another variant "cpu_relax_lowlatency" was introduced. Before this is used in more and more places, lets revert the logic and provide a cpu_relax_yield that can be called in places where yielding is more important than latency. By default this is the same as cpu_relax on all architectures. Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> --- arch/alpha/include/asm/processor.h | 1 + arch/arc/include/asm/processor.h...

...the hypervisor to give up the timeslice. In contrast to the SMT yielding this can result in larger latencies. In some places this latency is unwanted, so another variant "cpu_relax_lowlatency" was introduced. Before this is used in more and more places, lets revert the logic and provide a cpu_relax_yield that can be called in places where yielding is more important than latency. By default this is the same as cpu_relax on all architectures. So my proposal boils down to: - lowest latency: use barrier() or mb() if necessary - low latency: use cpu_relax (e.g. might give up some cpu for the other _h...

...the hypervisor to give up the timeslice. In contrast to the SMT yielding this can result in larger latencies. In some places this latency is unwanted, so another variant "cpu_relax_lowlatency" was introduced. Before this is used in more and more places, lets revert the logic and provide a cpu_relax_yield that can be called in places where yielding is more important than latency. By default this is the same as cpu_relax on all architectures. So my proposal boils down to: - lowest latency: use barrier() or mb() if necessary - low latency: use cpu_relax (e.g. might give up some cpu for the other _h...

...--git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h index 0556fda..31e8dbe 100644 --- a/arch/alpha/include/asm/processor.h +++ b/arch/alpha/include/asm/processor.h @@ -59,7 +59,6 @@ unsigned long get_wchan(struct task_struct *p); #define cpu_relax() barrier() #define cpu_relax_yield() cpu_relax() -#define cpu_relax_lowlatency() cpu_relax() #define ARCH_HAS_PREFETCH #define ARCH_HAS_PREFETCHW diff --git a/arch/arc/include/asm/processor.h b/arch/arc/include/asm/processor.h index 6c158d5..d102a49 100644 --- a/arch/arc/include/asm/processor.h +++ b/arch/arc/include/asm/process...

...ve up the timeslice. > In contrast to the SMT yielding this can result in larger latencies. > In some places this latency is unwanted, so another variant > "cpu_relax_lowlatency" was introduced. Before this is used in more > and more places, lets revert the logic and provide a cpu_relax_yield > that can be called in places where yielding is more important than > latency. By default this is the same as cpu_relax on all architectures. Rather than having to update all these architectures in this way, can't we put in some linux/*.h header something like: #ifndef cpu_relax_yield...

...ve up the timeslice. > In contrast to the SMT yielding this can result in larger latencies. > In some places this latency is unwanted, so another variant > "cpu_relax_lowlatency" was introduced. Before this is used in more > and more places, lets revert the logic and provide a cpu_relax_yield > that can be called in places where yielding is more important than > latency. By default this is the same as cpu_relax on all architectures. Rather than having to update all these architectures in this way, can't we put in some linux/*.h header something like: #ifndef cpu_relax_yield...

...n contrast to the SMT yielding this can result in larger latencies. > >> In some places this latency is unwanted, so another variant > >> "cpu_relax_lowlatency" was introduced. Before this is used in more > >> and more places, lets revert the logic and provide a cpu_relax_yield > >> that can be called in places where yielding is more important than > >> latency. By default this is the same as cpu_relax on all architectures. > > > > Rather than having to update all these architectures in this way, can't > > we put in some linux/*.h...

...n contrast to the SMT yielding this can result in larger latencies. > >> In some places this latency is unwanted, so another variant > >> "cpu_relax_lowlatency" was introduced. Before this is used in more > >> and more places, lets revert the logic and provide a cpu_relax_yield > >> that can be called in places where yielding is more important than > >> latency. By default this is the same as cpu_relax on all architectures. > > > > Rather than having to update all these architectures in this way, can't > > we put in some linux/*.h...

...ice. >> In contrast to the SMT yielding this can result in larger latencies. >> In some places this latency is unwanted, so another variant >> "cpu_relax_lowlatency" was introduced. Before this is used in more >> and more places, lets revert the logic and provide a cpu_relax_yield >> that can be called in places where yielding is more important than >> latency. By default this is the same as cpu_relax on all architectures. > > Rather than having to update all these architectures in this way, can't > we put in some linux/*.h header something like: &g...

...t to the SMT yielding this can result in larger latencies. >>>> In some places this latency is unwanted, so another variant >>>> "cpu_relax_lowlatency" was introduced. Before this is used in more >>>> and more places, lets revert the logic and provide a cpu_relax_yield >>>> that can be called in places where yielding is more important than >>>> latency. By default this is the same as cpu_relax on all architectures. >>> >>> Rather than having to update all these architectures in this way, can't >>> we put in s...

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: Christian Borntraeger <borntraeger at de.ibm.com> > --- > kernel/stop_machine.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/k...

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: Christian Borntraeger <borntraeger at de.ibm.com> > --- > kernel/stop_machine.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/k...

stop_machine seemed to be the only important place for yielding during cpu_relax. This was fixed by using cpu_relax_yield. Therefore, we can now redefine cpu_relax to be a barrier instead on s390, making s390 identical to all other architectures. Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> --- arch/s390/include/asm/processor.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --g...

...nfradead.org> wrote: > 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: Christian Borntraeger <borntraeger at de.ibm.com> > > --- > > kernel/stop_machine.c | 2 +- > > 1 file changed, 1 insertion(+...

...rote: > >> 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: Christian Borntraeger <borntraeger at de.ibm.com> >>> --- >>> kernel/stop_machine.c | 2 +- >>> 1 f...

...ce to the hypervisor. On power cpu_relax >> tries to give some of the CPU to the neighbor threads. To reduce the >> latency another variant cpu_relax_lowlatency was introduced. Before this >> is used in more and more places, lets revert the logic of provide a new >> function cpu_relax_yield that can spend some time and for s390 yields >> the guest CPU. > > Sparc64, fwiw, behaves similarly to powerpc. As sparc currently defines cpu_relax_lowlatency to cpu_relax, this patch set should be a no-op then for sparc, correct? My intend was that cpu_relax should not add a huge l...

...4d92f50249eb ("s390: reintroduce diag 44 calls for cpu_relax()"), but in fact the stop machine code seems to be the only place where this yielding was really necessary. This place is probably the most important one as it makes all but one guest CPUs wait for one guest CPU. As we now have cpu_relax_yield, we can use this in multi_cpu_stop. For now lets only add it here. We can add it later in other places when necessary. Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> --- kernel/stop_machine.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/stop_m...

...ce to the hypervisor. On power cpu_relax >> tries to give some of the CPU to the neighbor threads. To reduce the >> latency another variant cpu_relax_lowlatency was introduced. Before this >> is used in more and more places, lets revert the logic of provide a new >> function cpu_relax_yield that can spend some time and for s390 yields >> the guest CPU. > > Sparc64, fwiw, behaves similarly to powerpc. As sparc currently defines cpu_relax_lowlatency to cpu_relax, this patch set should be a no-op then for sparc, correct? My intend was that cpu_relax should not add a huge l...