Re: [PATCH] interrupt: discover and disable very frequent interrupts

[Marc Zyngier <maz@kernel.org>]

On Fri, 30 Sep 2022 10:57:17 +0100,
"=?utf-8?B?WmhhbmcgWGluY2hlbmc=?=" <zhangxincheng@uniontech.com> wrote:
> 
> > Irrespective of the patch itself, I would really like to understand
> > why you consider that it is a better course of action to kill a device
> > (and potentially the whole machine) than to let the storm eventually
> > calm down? A frequent interrupt is not necessarily the sign of
> > something going wrong. It is the sign of a busy system. I prefer my
> > systems busy rather than dead.
> 
> Because I found that some peripherals will send interrupts to the
> CPU very frequently in some cases, and the interrupts will be
> handled correctly, which will cause the CPU to do nothing but handle
> the interrupts. At the same time, the RCU system will report the
> following logs:
> 
> [  838.131628] rcu: INFO: rcu_sched self-detected stall on CPU
> [  838.137189] rcu:     0-....: (194839 ticks this GP) idle=f02/1/0x4000000000000004 softirq=9993/9993 fqs=97428 
> [  838.146912] rcu:      (t=195015 jiffies g=6773 q=0)
> [  838.151516] Task dump for CPU 0:
> [  838.154730] systemd-sleep   R  running task        0  3445      1 0x0000000a
> [  838.161764] Call trace:
> [  838.164198]  dump_backtrace+0x0/0x190
> [  838.167846]  show_stack+0x14/0x20
> [  838.171148]  sched_show_task+0x134/0x160
> [  838.175057]  dump_cpu_task+0x40/0x4c
> [  838.178618]  rcu_dump_cpu_stacks+0xc4/0x108
> [  838.182788]  rcu_check_callbacks+0x6e4/0x898
> [  838.187044]  update_process_times+0x2c/0x88
> [  838.191214]  tick_sched_handle.isra.5+0x3c/0x50
> [  838.195730]  tick_sched_timer+0x48/0x98
> [  838.199552]  __hrtimer_run_queues+0xec/0x2f8
> [  838.203808]  hrtimer_interrupt+0x10c/0x298
> [  838.207891]  arch_timer_handler_phys+0x2c/0x38
> [  838.212321]  handle_percpu_devid_irq+0x88/0x228
> [  838.216837]  generic_handle_irq+0x2c/0x40
> [  838.220833]  __handle_domain_irq+0x60/0xb8
> [  838.224915]  gic_handle_irq+0x7c/0x178
> [  838.228650]  el1_irq+0xb0/0x140
> [  838.231778]  __do_softirq+0x84/0x2e8
> [  838.235340]  irq_exit+0x9c/0xb8
> [  838.238468]  __handle_domain_irq+0x64/0xb8
> [  838.242550]  gic_handle_irq+0x7c/0x178
> [  838.246285]  el1_irq+0xb0/0x140
> [  838.249413]  resume_irqs+0xfc/0x148
> [  838.252888]  resume_device_irqs+0x10/0x18
> [  838.256883]  dpm_resume_noirq+0x10/0x20
> [  838.260706]  suspend_devices_and_enter+0x170/0x788
> [  838.265483]  pm_suspend+0x41c/0x4cc
> [  838.268958]  state_store+0xbc/0x160
> [  838.272433]  kobj_attr_store+0x14/0x28
> [  838.276168]  sysfs_kf_write+0x40/0x50
> [  838.279817]  kernfs_fop_write+0xcc/0x1e0
> [  838.283726]  __vfs_write+0x18/0x140
> [  838.287201]  vfs_write+0xa4/0x1b0
> [  838.290503]  ksys_write+0x4c/0xb8
> [  838.293804]  __arm64_sys_write+0x18/0x20
> [  838.297713]  el0_svc_common+0x90/0x178
> [  838.301449]  el0_svc_handler+0x9c/0xa8
> [  838.305184]  el0_svc+0x8/0xc
> 
> The log is from the process of waking up a sleeping machine, 
> I left the machine in this state for a night and it successfully woke up,
>  and then I saw from /proc/interrupts that a GPIO interrupt triggered 
> more than 13 billion times.
> 
> 29: 1368200001  0  0  0  0  0  0  0     phytium_gpio6   Edge ACPI:Event

Again: what makes you think that it is better to kill the interrupt
than suffering a RCU stall? Yes, that's a lot of interrupts. But
killing it and risking the whole system isn't an acceptable outcome.

	M.

-- 
Without deviation from the norm, progress is not possible.