lkml.org 
[lkml]   [2022]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] interrupt: discover and disable very frequent interrupts
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.

\
 
 \ /
  Last update: 2022-09-30 13:01    [W:0.049 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site