search for: cpu_relax_lowlat

With the s390 special case of a yielding cpu_relax implementation gone, we can now remove all users of cpu_relax_lowlatency and replace them with cpu_relax. Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> --- drivers/gpu/drm/i915/i915_gem_request.c | 2 +- drivers/vhost/net.c | 4 ++-- kernel/locking/mcs_spinlock.h | 4 ++-- kernel/locking/mutex.c...

As there are no users left, we can remove cpu_relax_lowlatency. Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> --- arch/alpha/include/asm/processor.h | 1 - arch/arc/include/asm/processor.h | 2 -- arch/arm/include/asm/processor.h | 1 - arch/arm64/include/asm/processor.h | 1 - arch/avr32/include/asm/proce...

...d1c0eb51ef87ff2eab5c994949e69: Linux 4.9-rc2 (2016-10-23 17:10:14 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git tags/cpurelax for you to fetch changes up to dcc37f9044436438360402714b7544a8e8779b07: processor.h: remove cpu_relax_lowlatency (2016-10-25 09:49:57 +0200) ---------------------------------------------------------------- cpu_relax: drop lowlatency, introduce yield For spinning loops people do often use barrier() or cpu_relax(). For most architectures cpu_relax and barrier are the same, but on some architectures cpu_re...

...d1c0eb51ef87ff2eab5c994949e69: Linux 4.9-rc2 (2016-10-23 17:10:14 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git tags/cpurelax for you to fetch changes up to dcc37f9044436438360402714b7544a8e8779b07: processor.h: remove cpu_relax_lowlatency (2016-10-25 09:49:57 +0200) ---------------------------------------------------------------- cpu_relax: drop lowlatency, introduce yield For spinning loops people do often use barrier() or cpu_relax(). For most architectures cpu_relax and barrier are the same, but on some architectures cpu_re...

...ift the CPU towards other hardware threads in an SMT environment. On s390 cpu_relax does even more, it uses an hypercall to 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...

...arrier are the same, but on >> some architectures cpu_relax can add some latency. For example on s390 >> cpu_relax gives up the time slice 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...

...arrier are the same, but on >> some architectures cpu_relax can add some latency. For example on s390 >> cpu_relax gives up the time slice 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...

...hardware threads in an SMT environment. > On s390 cpu_relax does even more, it uses an hypercall to 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. Rather than having to...

...hardware threads in an SMT environment. > On s390 cpu_relax does even more, it uses an hypercall to 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. Rather than having to...

...ith this. Thanks, Davidlohr > * vcpu_is_preempted is a macro defined by false if >+ * arch does not support vcpu preempted check, > */ >- if (need_resched()) >+ if (need_resched() || vcpu_is_preempted(node_cpu(node->prev))) > goto unqueue; > > cpu_relax_lowlatency(); >-- >2.4.11 >

...ith this. Thanks, Davidlohr > * vcpu_is_preempted is a macro defined by false if >+ * arch does not support vcpu preempted check, > */ >- if (need_resched()) >+ if (need_resched() || vcpu_is_preempted(node_cpu(node->prev))) > goto unqueue; > > cpu_relax_lowlatency(); >-- >2.4.11 >

...>> On s390 cpu_relax does even more, it uses an hypercall to 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 architectu...

...>> On s390 cpu_relax does even more, it uses an hypercall to 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 architectu...

...if (r == vq->num && vq->busyloop_timeout) { > + preempt_disable(); > + endtime = busy_clock() + vq->busyloop_timeout; > + while (vhost_can_busy_poll(vq->dev, endtime) && > + vhost_vq_avail_empty(vq->dev, vq)) > + cpu_relax(); Can you use cpu_relax_lowlatency (which should be the same as cpu_relax for almost everybody but s390? cpu_relax (without low latency might give up the time slice when running under another hypervisor (like LPAR on s390), which might not be what we want here. [...] > +static int vhost_net_rx_peek_head_len(struct vhost_n...

...if (r == vq->num && vq->busyloop_timeout) { > + preempt_disable(); > + endtime = busy_clock() + vq->busyloop_timeout; > + while (vhost_can_busy_poll(vq->dev, endtime) && > + vhost_vq_avail_empty(vq->dev, vq)) > + cpu_relax(); Can you use cpu_relax_lowlatency (which should be the same as cpu_relax for almost everybody but s390? cpu_relax (without low latency might give up the time slice when running under another hypervisor (like LPAR on s390), which might not be what we want here. [...] > +static int vhost_net_rx_peek_head_len(struct vhost_n...

...+42% 16384/ 4/ -3%/ -3%/ -4%/ +5%/ +115% 16384/ 8/ -1%/ 0%/ -1%/ -3%/ +32% 65535/ 1/ +1%/ 0%/ +2%/ 0%/ +66% 65535/ 4/ -1%/ -1%/ 0%/ +4%/ +492% 65535/ 8/ 0%/ -1%/ -1%/ +4%/ +38% Changes from V3: - drop single_task_running() - use cpu_relax_lowlatency() instead of cpu_relax() Changes from V2: - rename vhost_vq_more_avail() to vhost_vq_avail_empty(). And return false we __get_user() fails. - do not bother premmptions/timers for good path. - use vhost_vring_state as ioctl parameter instead of reinveting a new one. - add the unit of timeout (u...

...+42% 16384/ 4/ -3%/ -3%/ -4%/ +5%/ +115% 16384/ 8/ -1%/ 0%/ -1%/ -3%/ +32% 65535/ 1/ +1%/ 0%/ +2%/ 0%/ +66% 65535/ 4/ -1%/ -1%/ 0%/ +4%/ +492% 65535/ 8/ 0%/ -1%/ -1%/ +4%/ +38% Changes from V3: - drop single_task_running() - use cpu_relax_lowlatency() instead of cpu_relax() Changes from V2: - rename vhost_vq_more_avail() to vhost_vq_avail_empty(). And return false we __get_user() fails. - do not bother premmptions/timers for good path. - use vhost_vring_state as ioctl parameter instead of reinveting a new one. - add the unit of timeout (u...

...sm/processor.h index d05965b..5d262cf 100644 --- a/arch/s390/include/asm/processor.h +++ b/arch/s390/include/asm/processor.h @@ -236,7 +236,7 @@ static inline unsigned short stap(void) */ void cpu_relax_yield(void); -#define cpu_relax() cpu_relax_yield() +#define cpu_relax() barrier() #define cpu_relax_lowlatency() barrier() #define ECAG_CACHE_ATTRIBUTE 0 -- 2.5.5

...Use vcpu_is_preempted to detech lock holder preemption issue + * and break. vcpu_is_preempted is a macro defined by false if + * arch does not support vcpu preempted check, */ - if (need_resched()) + if (need_resched() || vcpu_is_preempted(node_cpu(node->prev))) goto unqueue; cpu_relax_lowlatency(); -- 2.4.11

...an SMT environment. >> On s390 cpu_relax does even more, it uses an hypercall to 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. > >...