Messages in this thread |  | | Date | Fri, 6 Sep 2019 08:18:58 -0600 | From | Keith Busch <> | Subject | Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism |
| |
On Fri, Sep 06, 2019 at 09:48:21AM +0800, Ming Lei wrote: > When one IRQ flood happens on one CPU: > > 1) softirq handling on this CPU can't make progress > > 2) kernel thread bound to this CPU can't make progress > > For example, network may require softirq to xmit packets, or another irq > thread for handling keyboards/mice or whatever, or rcu_sched may depend > on that CPU for making progress, then the irq flood stalls the whole > system. > > > > > AFAIU, there are fast medium where the responses to requests are faster > > than the time to process them, right? > > Usually medium may not be faster than CPU, now we are talking about > interrupts, which can be originated from lots of devices concurrently, > for example, in Long Li'test, there are 8 NVMe drives involved.
Why are all 8 nvmes sharing the same CPU for interrupt handling? Shouldn't matrix_find_best_cpu_managed() handle selecting the least used CPU from the cpumask for the effective interrupt handling?
|  |