Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.

On Wed, Oct 21, 2015 at 04:16:31PM +0530, Viresh Kumar wrote: > Cc'ing Frederic. > > On 20-10-15, 15:47, Yunhong Jiang wrote: > > On Sun, Oct 11, 2015 at 08:12:39PM +0200, Thomas Gleixner wrote: > > > On Mon, 28 Sep 2015, Yunhong Jiang wrote: > > > > s

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote: > On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote: > > An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ, > > even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when > > assignin

[RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

in kernel irq_chip is enabled. It provides more flexibility but is more complex, not sure if we need go through that way. Signed-off-by: Yunhong Jiang <yunhong.ji...@linux.intel.com> --- drivers/vfio/pci/vfio_pci_intrs.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Tue, Oct 27, 2015 at 10:29:28AM +0100, Paolo Bonzini wrote: > > > On 27/10/2015 07:35, Yunhong Jiang wrote: > > On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote: > >> On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote: > >>> An option

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Wed, Oct 28, 2015 at 01:44:55AM +0100, Paolo Bonzini wrote: > > > On 27/10/2015 22:26, Yunhong Jiang wrote: > >> > On RT kernels however can you call eventfd_signal from interrupt > >> > context? You cannot call spin_lock_irqsave (which can sleep) from a >

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Wed, Oct 28, 2015 at 12:18:48PM -0600, Alex Williamson wrote: > On Wed, 2015-10-28 at 10:50 -0700, Yunhong Jiang wrote: > > On Wed, Oct 28, 2015 at 01:44:55AM +0100, Paolo Bonzini wrote: > > It's in linux-next via the kvm.git next branch: > > git://git.kernel.org/pub

Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.

On Sat, Oct 24, 2015 at 08:50:54AM +0530, Viresh Kumar wrote: > On 23-10-15, 15:10, Yunhong Jiang wrote: > > I got this impression from Frederic's comments on > > http://marc.info/?l=linux-kernel=139048415303210=2, "So you simply rely > > on the next tick to see the n

Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.

On Fri, Oct 23, 2015 at 07:49:51AM +0530, Viresh Kumar wrote: > On 22-10-15, 14:40, Yunhong Jiang wrote: > > A naive question is, why it's sure a tick will happen when the tickless > > processor is in idle? > > How do you get this impression? I don't think anyone has said

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Thu, Oct 29, 2015 at 10:45:44AM +0100, Paolo Bonzini wrote: > > > On 29/10/2015 04:11, Alex Williamson wrote: > > > The irqfd is already able to schedule a work item, because it runs with > > > interrupts disabled, so I think we can always return IRQ_HANDLED. > > > > I'm confused by this.

Can srcu_read_lock() be called from interrupt context?

Hi, Paul I have a question to the srcu_read_lock(). Can it be invoked on interrupt context? According to http://lxr.free-electrons.com/source/kernel/rcu/srcu.c#L292 it can only be called from process context, but according to

Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.

On Sun, Oct 11, 2015 at 08:12:39PM +0200, Thomas Gleixner wrote: > On Mon, 28 Sep 2015, Yunhong Jiang wrote: > > static void internal_add_timer(struct tvec_base *base, struct timer_list > > *timer) > > { > > + bool kick_nohz = false; > > + > >

Re: [RFC] nohz: no update idle entry time on get_cpu_idle/iowait_time_us()

On Sun, Oct 11, 2015 at 08:38:17PM +0200, Thomas Gleixner wrote: > On Mon, 28 Sep 2015, Yunhong Jiang wrote: > > Currently the get_cpu_idle/iowait_time_us() updates the idle_entrytime. > > When it's invoked from another CPU and the target CPU has been on idle > > al

[PATCH] nohz: make the idle_entrytime/idle_exittime correct

the idle_entrytime to be updated only when enter idle, the idle_exittime to be updated only when exit idle. Update the get_cpu_idle_iowait_time_us() accordingly. Signed-off-by: Yunhong Jiang <yunhong.ji...@linux.intel.com> --- kernel/time/tick-sched.

[PATCH] timer: Lazily wakup nohz CPU when adding new timer.

U 8: 135 88 CPU 9: 238 43 CPU 10: 157 83 CPU 11: 172 70 Signed-off-by: Yunhong Jiang <yunhong.ji...@linux.intel.com> --- kernel/time/timer.c | 21 ++--- 1 file changed, 14 insertions(+), 7

[RFC] nohz: no update idle entry time on get_cpu_idle/iowait_time_us()

update_ts_time_stats() and clear ts->idle_active, that get_cpu_idle/iowait_time_us(), when invoked remotely, may double count last idle period. This window exists w/o this change and this change does not fix it. Signed-off-by: Yunhong Jiang <yunhong.ji...@linux.intel.com> --- kernel/time/tic

Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.

Ping for any response. Thanks --jyh On Mon, Sep 28, 2015 at 11:48:16AM -0700, Yunhong Jiang wrote: > Currently, when a new timer added to timer wheel for a nohz_active CPU, > the target CPU will always be waked up. > > In fact, if the new added timer is after the base->next_

Re: [PATCH] nohz: make the idle_entrytime/idle_exittime correct

On Thu, Sep 17, 2015 at 11:45:37PM +0200, Thomas Gleixner wrote: > On Wed, 16 Sep 2015, Yunhong Jiang wrote: > > > Currently the idle_entrytime is updated on idle_entry, idle_exit and > > get_cpu_idle/iowait_time_us() with non-NULL parameter. This makes the > > idl

Can we conditionally force threading irq with primary and thread handler?

Hi, Thomas On Commit 2a1d3ab8986d1b2 ("genirq: Handle force threading of irqs with primary and thread handler"), even if the caller of request_threaded_irq() provides a primary handler, that primary handler will be invoked in thread context. This may cause some latency issue for high

Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

On Thu, Dec 03, 2015 at 11:55:53AM -0700, Alex Williamson wrote: > On Thu, 2015-12-03 at 10:22 -0800, Yunhong Jiang wrote: > > When assigning a VFIO device to a KVM guest with low latency requirement, > > it > > is better to handle the interrupt in the hard interru

Re: Can we conditionally force threading irq with primary and thread handler?

On Thu, Dec 03, 2015 at 11:33:14PM +0100, Thomas Gleixner wrote: > Yunhong, > > On Thu, 3 Dec 2015, Yunhong Jiang wrote: > > > Hi, Thomas > > On Commit 2a1d3ab8986d1b2 ("genirq: Handle force threading of irqs > > with primary and t

[PATCH 2/5] VIRT: Support runtime irq_bypass consumer

to support both static consumer (like for Posted Interrupt consumer) and runtime consumer. Signed-off-by: Yunhong Jiang <yunhong.ji...@linux.intel.com> --- include/linux/irqbypass.h | 8 + virt/lib/irqbypass.c | 82 +++ 2 files chang

[PATCH 5/5] KVM: Expose x86 kvm_arch_set_irq_inatomic()

The x86 support setting irq in atomic, expose it to vfio driver. Signed-off-by: Yunhong Jiang <yunhong.ji...@linux.intel.com> --- arch/x86/kvm/Kconfig | 1 + include/linux/kvm_host.h | 19 --- virt/kvm/Kconfig | 3 +++ virt/kvm/eventfd.c | 9 --

[PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

the interrupt at hard interrupt context. The producer will invoke the consumer's handler then. Yunhong Jiang (5): Extract the irqfd_wakeup_pollin/irqfd_wakeup_pollup Support runtime irq_bypass consumer Support threaded interrupt handling on VFIO Add the irq handling consumer Expose x86

[PATCH 1/5] KVM: Extract the irqfd_wakeup_pollin/irqfd_wakeup_pollup

Separate the irqfd_wakeup_pollin/irqfd_wakeup_pollup from the irqfd_wakeup, so that we can reuse the logic for MSI fastpath injection. Signed-off-by: Yunhong Jiang <yunhong.ji...@linux.intel.com> --- virt/kvm/eventfd.c | 86 -- 1 file c

[PATCH 3/5] VFIO: Support threaded interrupt handling on VFIO

For VFIO device with MSI interrupt type, it's possible to handle the interrupt on hard interrupt context without invoking the interrupt thread. Handling the interrupt on hard interrupt context reduce the interrupt latency. Signed-off-by: Yunhong Jiang <yunhong.ji...@linux.intel.com> --- d

[PATCH 4/5] KVM: Add the irq handling consumer

Add an irq_bypass consumer to the KVM eventfd, so that when a MSI interrupt happens and triggerred from VFIO, it can be handled fast. Signed-off-by: Yunhong Jiang <yunhong.ji...@linux.intel.com> --- include/linux/kvm_irqfd.h | 1 + virt/kvm/eventfd.c

Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

On Wed, Dec 16, 2015 at 10:55:12PM +0100, Paolo Bonzini wrote: > > > On 16/12/2015 20:15, Alex Williamson wrote: > > The consumers would be, for instance, Intel PI + the threaded handler > > added in this series. These run independently, the PI bypass simply > > makes the interrupt disappear

Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

s --jyh > still need the srcu code added here to protect against registration and > irq_handler() races.  Thanks, > > Alex > > > On 03/12/2015 19:22, Yunhong Jiang wrote: > > > When assigning a VFIO device to a KVM guest with low latency > > > requirement, it   >

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

On Fri, 27 May 2016 11:49:26 +0200 Paolo Bonzini <pbonz...@redhat.com> wrote: > > > On 26/05/2016 22:33, yunhong jiang wrote: > > On Thu, 26 May 2016 12:26:27 +0200 > > Paolo Bonzini <pbonz...@redhat.com> wrote: > > > >> > >> > >

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

On Thu, 26 May 2016 12:26:27 +0200 Paolo Bonzini wrote: > > > On 25/05/2016 04:47, Wanpeng Li wrote: > > From: Wanpeng Li > > > > If an emulated lapic timer will fire soon(in the scope of 10us the > > base of dynamic halt-polling, lower-end of

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

On Tue, 28 Jun 2016 13:56:38 -0400 (EDT) Paolo Bonzini wrote: > > > > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > > index fdc05ae..b15e32a 100644 > > > --- a/arch/x86/kvm/lapic.c > > > +++ b/arch/x86/kvm/lapic.c > > > @@ -1454,11 +1454,18 @@ static void

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

ous programmed preemption > timer if there is once we failed to program the new preemption timer > and fallback to hrtimer based method. Hi, WanPeng, thanks for the patch. > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Radim Krčmář <rkrc...@redhat.com> > Cc: Yunhong

Re: [RFT PATCH v5 3/3] KVM: nVMX: keep preemption timer enabled during L2 execution

On Fri, 8 Jul 2016 14:02:13 +0200 Paolo Bonzini wrote: > Because the vmcs12 preemption timer is emulated through a separate > hrtimer, we can keep on using the preemption timer in the vmcs02 to > emulare L1's TSC deadline timer. > > However, the corresponding bit in the

Re: [RFT PATCH v5 3/3] KVM: nVMX: keep preemption timer enabled during L2 execution

On Fri, 8 Jul 2016 19:41:48 +0200 Paolo Bonzini <pbonz...@redhat.com> wrote: > > > On 08/07/2016 19:29, yunhong jiang wrote: > > > > > > exec_control = vmcs12->pin_based_vm_exec_control; > > > - exec_control |= vmcs_config.pin_based_exec_ctrl

Re: [RFT PATCH v5 3/3] KVM: nVMX: keep preemption timer enabled during L2 execution

On Fri, 8 Jul 2016 17:39:22 -0400 (EDT) Paolo Bonzini wrote: > > > > > @@ -10727,8 +10732,14 @@ static void nested_vmx_vmexit(struct > > > > > kvm_vcpu *vcpu, u32 exit_reason, > > > > > load_vmcs12_host_state(vcpu, vmcs12); > > > > > > > > > > - /* Update

Re: [PATCH v4 1/2] KVM: nVMX: Fix incorrect preemption timer vmexit in nested guest

ULL > > pointer. > > > > This patch fix it by depending on check_nested_events to capture L2 > > preemption timer(emulated hrtimer) expire and nested vmexit. > > > > Tested-by: Haozhong Zhang <haozhong.zh...@intel.com> > > Cc: Paolo Bonzini <p

The timer softirq on the RT kernel

Hi,Mike & Steven On https://lkml.org/lkml/2015/3/24/1178, the patch of "timers: do not raise softirq unconditionally" is reverted. Thanks for Steven's detailed comments, it's quite clear explained. I remember Mike has a patch trying to fix it but late abandoned. Do you still have

Re: The timer softirq on the RT kernel

On Fri, 05 Aug 2016 04:36:23 +0200 Mike Galbraith <umgwanakikb...@gmail.com> wrote: > On Thu, 2016-08-04 at 17:36 -0700, yunhong jiang wrote: > > Hi,Mike & Steven > > On https://lkml.org/lkml/2015/3/24/1178, the patch of > > "timers: do not raise softirq

Re: [PATCH v2 1/2] KVM: x86: introduce cancel_hv_tscdeadline

Radim Krčmář <rkrc...@redhat.com> > Cc: Yunhong Jiang <yunhong.ji...@intel.com> > Signed-off-by: Wanpeng Li <wanpeng...@hotmail.com> It's ok for me, thanks for the patch, Wanpeng. --jyh > --- > arch/x86/kvm/lapic.c | 18 ++ > 1 file changed, 1

Re: [PATCH v2 2/2] KVM: x86: fix underflow in TSC deadline calculation

as above. > > This patch fix it by cancelling the previous programmed preemption > timer if there is once we failed to program the new preemption timer > and fallback to hrtimer based method. > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Radim Krčmář <rkr

Questions on the task isolation patches

Hi, Chris I noticed your task isolation patch set at https://lkml.org/lkml/2016/8/9/759 . Thanks a lot for the great effort. I checked the patch and have some questions about how to use this functionality on the NFV environment. In the NFV scenario, high speed network code runs on a VM

Re: Questions on the task isolation patches

On Fri, 2 Dec 2016 13:58:08 -0500 Chris Metcalf <cmetc...@mellanox.com> wrote: > On 12/1/2016 5:28 PM, yunhong jiang wrote: > > Hi, Chris > > I noticed your task isolation patch set at > > https://lkml.org/lkml/2016/8/9/759 . Thanks a lot for the great > &g

Re: Questions on the task isolation patches

On Fri, 16 Dec 2016 16:00:48 -0500 Chris Metcalf <cmetc...@mellanox.com> wrote: > Sorry for the slow response - I have been busy with some other things. Thanks for the reply. > > On 12/6/2016 4:43 PM, yunhong jiang wrote: > > On Fri, 2 Dec 2016 13:58:08 -0500 >

Re: Questions on the task isolation patches

On Fri, 2 Dec 2016 13:58:08 -0500 Chris Metcalf wrote: > On 12/1/2016 5:28 PM, yunhong jiang wrote: > > Hi, Chris > > I noticed your task isolation patch set at > > https://lkml.org/lkml/2016/8/9/759 . Thanks a lot for the great > > effort. > > > >

Re: Questions on the task isolation patches

On Fri, 16 Dec 2016 16:00:48 -0500 Chris Metcalf wrote: > Sorry for the slow response - I have been busy with some other things. Thanks for the reply. > > On 12/6/2016 4:43 PM, yunhong jiang wrote: > > On Fri, 2 Dec 2016 13:58:08 -0500 > > Chris Metcalf wrote: > >

Questions on the task isolation patches

Hi, Chris I noticed your task isolation patch set at https://lkml.org/lkml/2016/8/9/759 . Thanks a lot for the great effort. I checked the patch and have some questions about how to use this functionality on the NFV environment. In the NFV scenario, high speed network code runs on a VM

Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.

Ping for any response. Thanks --jyh On Mon, Sep 28, 2015 at 11:48:16AM -0700, Yunhong Jiang wrote: > Currently, when a new timer added to timer wheel for a nohz_active CPU, > the target CPU will always be waked up. > > In fact, if the new added timer is after the base->next_

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Tue, Oct 27, 2015 at 10:29:28AM +0100, Paolo Bonzini wrote: > > > On 27/10/2015 07:35, Yunhong Jiang wrote: > > On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote: > >> On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote: > >>> An option

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Wed, Oct 28, 2015 at 01:44:55AM +0100, Paolo Bonzini wrote: > > > On 27/10/2015 22:26, Yunhong Jiang wrote: > >> > On RT kernels however can you call eventfd_signal from interrupt > >> > context? You cannot call spin_lock_irqsave (which can sleep) from a >

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Wed, Oct 28, 2015 at 12:18:48PM -0600, Alex Williamson wrote: > On Wed, 2015-10-28 at 10:50 -0700, Yunhong Jiang wrote: > > On Wed, Oct 28, 2015 at 01:44:55AM +0100, Paolo Bonzini wrote: > > It's in linux-next via the kvm.git next branch: > > git://git.kernel.org/pub

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Thu, Oct 29, 2015 at 10:45:44AM +0100, Paolo Bonzini wrote: > > > On 29/10/2015 04:11, Alex Williamson wrote: > > > The irqfd is already able to schedule a work item, because it runs with > > > interrupts disabled, so I think we can always return IRQ_HANDLED. > > > > I'm confused by this.

Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.

On Sun, Oct 11, 2015 at 08:12:39PM +0200, Thomas Gleixner wrote: > On Mon, 28 Sep 2015, Yunhong Jiang wrote: > > static void internal_add_timer(struct tvec_base *base, struct timer_list > > *timer) > > { > > + bool kick_nohz = false; > > + > >

Re: [RFC] nohz: no update idle entry time on get_cpu_idle/iowait_time_us()

On Sun, Oct 11, 2015 at 08:38:17PM +0200, Thomas Gleixner wrote: > On Mon, 28 Sep 2015, Yunhong Jiang wrote: > > Currently the get_cpu_idle/iowait_time_us() updates the idle_entrytime. > > When it's invoked from another CPU and the target CPU has been on idle > > al

Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.

On Wed, Oct 21, 2015 at 04:16:31PM +0530, Viresh Kumar wrote: > Cc'ing Frederic. > > On 20-10-15, 15:47, Yunhong Jiang wrote: > > On Sun, Oct 11, 2015 at 08:12:39PM +0200, Thomas Gleixner wrote: > > > On Mon, 28 Sep 2015, Yunhong Jiang wrote: > > > > s

Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.

On Fri, Oct 23, 2015 at 07:49:51AM +0530, Viresh Kumar wrote: > On 22-10-15, 14:40, Yunhong Jiang wrote: > > A naive question is, why it's sure a tick will happen when the tickless > > processor is in idle? > > How do you get this impression? I don't think anyone has said

Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.

On Sat, Oct 24, 2015 at 08:50:54AM +0530, Viresh Kumar wrote: > On 23-10-15, 15:10, Yunhong Jiang wrote: > > I got this impression from Frederic's comments on > > http://marc.info/?l=linux-kernel=139048415303210=2, "So you simply rely > > on the next tick to see the n

[RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

in kernel irq_chip is enabled. It provides more flexibility but is more complex, not sure if we need go through that way. Signed-off-by: Yunhong Jiang --- drivers/vfio/pci/vfio_pci_intrs.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/vfio/pci

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote: > On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote: > > An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ, > > even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when > > assignin

[PATCH 5/5] KVM: Expose x86 kvm_arch_set_irq_inatomic()

The x86 support setting irq in atomic, expose it to vfio driver. Signed-off-by: Yunhong Jiang --- arch/x86/kvm/Kconfig | 1 + include/linux/kvm_host.h | 19 --- virt/kvm/Kconfig | 3 +++ virt/kvm/eventfd.c | 9 - 4 files changed, 20 insertions(+), 12

[PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

the interrupt at hard interrupt context. The producer will invoke the consumer's handler then. Yunhong Jiang (5): Extract the irqfd_wakeup_pollin/irqfd_wakeup_pollup Support runtime irq_bypass consumer Support threaded interrupt handling on VFIO Add the irq handling consumer Expose x86

[PATCH 2/5] VIRT: Support runtime irq_bypass consumer

to support both static consumer (like for Posted Interrupt consumer) and runtime consumer. Signed-off-by: Yunhong Jiang --- include/linux/irqbypass.h | 8 + virt/lib/irqbypass.c | 82 +++ 2 files changed, 69 insertions(+), 21 deletions(-) diff

[PATCH 4/5] KVM: Add the irq handling consumer

Add an irq_bypass consumer to the KVM eventfd, so that when a MSI interrupt happens and triggerred from VFIO, it can be handled fast. Signed-off-by: Yunhong Jiang --- include/linux/kvm_irqfd.h | 1 + virt/kvm/eventfd.c| 42 ++ 2 files changed, 43

[PATCH 3/5] VFIO: Support threaded interrupt handling on VFIO

For VFIO device with MSI interrupt type, it's possible to handle the interrupt on hard interrupt context without invoking the interrupt thread. Handling the interrupt on hard interrupt context reduce the interrupt latency. Signed-off-by: Yunhong Jiang --- drivers/vfio/pci/vfio_pci_intrs.c | 39

[PATCH 1/5] KVM: Extract the irqfd_wakeup_pollin/irqfd_wakeup_pollup

Separate the irqfd_wakeup_pollin/irqfd_wakeup_pollup from the irqfd_wakeup, so that we can reuse the logic for MSI fastpath injection. Signed-off-by: Yunhong Jiang --- virt/kvm/eventfd.c | 86 -- 1 file changed, 51 insertions(+), 35 deletions

Can we conditionally force threading irq with primary and thread handler?

Hi, Thomas On Commit 2a1d3ab8986d1b2 ("genirq: Handle force threading of irqs with primary and thread handler"), even if the caller of request_threaded_irq() provides a primary handler, that primary handler will be invoked in thread context. This may cause some latency issue for high

Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

On Thu, Dec 03, 2015 at 11:55:53AM -0700, Alex Williamson wrote: > On Thu, 2015-12-03 at 10:22 -0800, Yunhong Jiang wrote: > > When assigning a VFIO device to a KVM guest with low latency requirement, > > it > > is better to handle the interrupt in the hard interru

Re: Can we conditionally force threading irq with primary and thread handler?

On Thu, Dec 03, 2015 at 11:33:14PM +0100, Thomas Gleixner wrote: > Yunhong, > > On Thu, 3 Dec 2015, Yunhong Jiang wrote: > > > Hi, Thomas > > On Commit 2a1d3ab8986d1b2 ("genirq: Handle force threading of irqs > > with primary and t

The timer softirq on the RT kernel

Hi,Mike & Steven On https://lkml.org/lkml/2015/3/24/1178, the patch of "timers: do not raise softirq unconditionally" is reverted. Thanks for Steven's detailed comments, it's quite clear explained. I remember Mike has a patch trying to fix it but late abandoned. Do you still have

Re: The timer softirq on the RT kernel

On Fri, 05 Aug 2016 04:36:23 +0200 Mike Galbraith wrote: > On Thu, 2016-08-04 at 17:36 -0700, yunhong jiang wrote: > > Hi,Mike & Steven > > On https://lkml.org/lkml/2015/3/24/1178, the patch of > > "timers: do not raise softirq unconditionally" i

Re: [PATCH v4 1/2] KVM: nVMX: Fix incorrect preemption timer vmexit in nested guest

ook. However, nested_vmx_exit_handled is > > always return true for preemption timer vmexit, then the L1 > > preemption timer vmexit is captured and be treated as a L2 > > preemption timer vmexit, incurr a nested vmexit dereference NULL > > pointer. > > > > This pat

Re: [RFT PATCH v5 3/3] KVM: nVMX: keep preemption timer enabled during L2 execution

On Fri, 8 Jul 2016 14:02:13 +0200 Paolo Bonzini wrote: > Because the vmcs12 preemption timer is emulated through a separate > hrtimer, we can keep on using the preemption timer in the vmcs02 to > emulare L1's TSC deadline timer. > > However, the corresponding bit in the pin-based execution

Re: [RFT PATCH v5 3/3] KVM: nVMX: keep preemption timer enabled during L2 execution

On Fri, 8 Jul 2016 19:41:48 +0200 Paolo Bonzini wrote: > > > On 08/07/2016 19:29, yunhong jiang wrote: > > > > > > exec_control = vmcs12->pin_based_vm_exec_control; > > > - exec_control |= vmcs_config.pin_based_exec_ctrl; > > > + > &

Re: [RFT PATCH v5 3/3] KVM: nVMX: keep preemption timer enabled during L2 execution

On Fri, 8 Jul 2016 17:39:22 -0400 (EDT) Paolo Bonzini wrote: > > > > > @@ -10727,8 +10732,14 @@ static void nested_vmx_vmexit(struct > > > > > kvm_vcpu *vcpu, u32 exit_reason, > > > > > load_vmcs12_host_state(vcpu, vmcs12); > > > > > > > > > > - /* Update TSC_OFFSET if TSC was

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

on > timer if there is once we failed to program the new preemption timer > and fallback to hrtimer based method. Hi, WanPeng, thanks for the patch. > > Cc: Paolo Bonzini > Cc: Radim Krčmář > Cc: Yunhong Jiang > Signed-off-by: Wanpeng Li > --- > arch/x86/kvm/lapic.c |

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

On Tue, 28 Jun 2016 13:56:38 -0400 (EDT) Paolo Bonzini wrote: > > > > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > > index fdc05ae..b15e32a 100644 > > > --- a/arch/x86/kvm/lapic.c > > > +++ b/arch/x86/kvm/lapic.c > > > @@ -1454,11 +1454,18 @@ static void

Re: [PATCH v2 1/2] KVM: x86: introduce cancel_hv_tscdeadline

On Wed, 29 Jun 2016 19:23:56 +0800 Wanpeng Li wrote: > From: Wanpeng Li > > Introduce cancel_hv_tscdeadline() to encapsulate preemption > timer cancel stuff. > > Cc: Paolo Bonzini > Cc: Radim Krčmář > Cc: Yunhong Jiang > Signed-off-by: Wanpeng Li It's ok f

Re: [PATCH v2 2/2] KVM: x86: fix underflow in TSC deadline calculation

ous programmed preemption > timer if there is once we failed to program the new preemption timer > and fallback to hrtimer based method. > > Cc: Paolo Bonzini > Cc: Radim Krčmář > Cc: Yunhong Jiang > Signed-off-by: Wanpeng Li > --- > v1 -> v2: > * abstract

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

On Fri, 27 May 2016 11:49:26 +0200 Paolo Bonzini wrote: > > > On 26/05/2016 22:33, yunhong jiang wrote: > > On Thu, 26 May 2016 12:26:27 +0200 > > Paolo Bonzini wrote: > > > >> > >> > >> On 25/05/2016 04:47, Wanpeng Li wrote: > >

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

On Thu, 26 May 2016 12:26:27 +0200 Paolo Bonzini wrote: > > > On 25/05/2016 04:47, Wanpeng Li wrote: > > From: Wanpeng Li > > > > If an emulated lapic timer will fire soon(in the scope of 10us the > > base of dynamic halt-polling, lower-end of message passing workload > > latency TCP_RR's

[PATCH] nohz: make the idle_entrytime/idle_exittime correct

the idle_entrytime to be updated only when enter idle, the idle_exittime to be updated only when exit idle. Update the get_cpu_idle_iowait_time_us() accordingly. Signed-off-by: Yunhong Jiang --- kernel/time/tick-sched.c | 44 1 file changed, 16 insertions

Re: [PATCH] nohz: make the idle_entrytime/idle_exittime correct

On Thu, Sep 17, 2015 at 11:45:37PM +0200, Thomas Gleixner wrote: > On Wed, 16 Sep 2015, Yunhong Jiang wrote: > > > Currently the idle_entrytime is updated on idle_entry, idle_exit and > > get_cpu_idle/iowait_time_us() with non-NULL parameter. This makes the > > idl

Can srcu_read_lock() be called from interrupt context?

Hi, Paul I have a question to the srcu_read_lock(). Can it be invoked on interrupt context? According to http://lxr.free-electrons.com/source/kernel/rcu/srcu.c#L292 it can only be called from process context, but according to

[RFC] nohz: no update idle entry time on get_cpu_idle/iowait_time_us()

update_ts_time_stats() and clear ts->idle_active, that get_cpu_idle/iowait_time_us(), when invoked remotely, may double count last idle period. This window exists w/o this change and this change does not fix it. Signed-off-by: Yunhong Jiang --- kernel/time/tick-sched.c |

[PATCH] timer: Lazily wakup nohz CPU when adding new timer.

U 8: 135 88 CPU 9: 238 43 CPU 10: 157 83 CPU 11: 172 70 Signed-off-by: Yunhong Jiang --- kernel/time/timer.c | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/kernel/time/time

Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

s --jyh > still need the srcu code added here to protect against registration and > irq_handler() races.  Thanks, > > Alex > > > On 03/12/2015 19:22, Yunhong Jiang wrote: > > > When assigning a VFIO device to a KVM guest with low latency > > > requirement, it   >

Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

On Wed, Dec 16, 2015 at 10:55:12PM +0100, Paolo Bonzini wrote: > > > On 16/12/2015 20:15, Alex Williamson wrote: > > The consumers would be, for instance, Intel PI + the threaded handler > > added in this series. These run independently, the PI bypass simply > > makes the interrupt disappear