[lkml]   [2019]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/3] fix interrupt swamp in NVMe
On Tue, Aug 20, 2019 at 2:14 PM <> wrote:
> From: Long Li <>
> This patch set tries to fix interrupt swamp in NVMe devices.
> On large systems with many CPUs, a number of CPUs may share one NVMe hardware
> queue. It may have this situation where several CPUs are issuing I/Os, and
> all the I/Os are returned on the CPU where the hardware queue is bound to.
> This may result in that CPU swamped by interrupts and stay in interrupt mode
> for extended time while other CPUs continue to issue I/O. This can trigger
> Watchdog and RCU timeout, and make the system unresponsive.
> This patch set addresses this by enforcing scheduling and throttling I/O when
> CPU is starved in this situation.
> Long Li (3):
> sched: define a function to report the number of context switches on a
> sched: export idle_cpu()
> nvme: complete request in work queue on CPU with flooded interrupts
> drivers/nvme/host/core.c | 57 +++++++++++++++++++++++++++++++++++++++-
> drivers/nvme/host/nvme.h | 1 +
> include/linux/sched.h | 2 ++
> kernel/sched/core.c | 7 +++++
> 4 files changed, 66 insertions(+), 1 deletion(-)

Another simpler solution may be to complete request in threaded interrupt
handler for this case. Meantime allow scheduler to run the interrupt thread
handler on CPUs specified by the irq affinity mask, which was discussed by
the following link:

Could you try the above solution and see if the lockup can be avoided?
John Garry
should have workable patch.

Ming Lei

 \ /
  Last update: 2019-08-20 10:26    [W:0.154 / U:1.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site