Re: [PATCH v4 1/2] timers: Don't wake ktimersoftd on every tick

I found the problem: Running `dumpcap -D` (E.g. by wireshark) creates a timer that's sometimes re-armed with 0 timeout in it's callback function prb_retire_rx_blk_timer_expired(). My change introduced a subtle change in __run_timers()'s stop condition, which causes ktimersoftd to spin when such

Re: [PATCH v4 1/2] timers: Don't wake ktimersoftd on every tick

Hi Daniel, I didn't have time to look at it yet, aside from confirming Mike's issue reproduces on my machine. It's still on my backlog to investigate. -- Haris On 06/19/2018 07:43 AM, Daniel Bristot de Oliveira wrote: On 04/12/2018 05:00 PM, Haris Okanovic wrote: Hi Mike, I haven't test

Re: [PATCH v4 1/2] timers: Don't wake ktimersoftd on every tick

On 04/12/2018 05:00 PM, Haris Okanovic wrote: > Hi Mike, > > I haven't tested the patch with wireshark until now. My system also > hangs shortly after it starts. I'm pretty sure I hit workqueues in my > earlier tests via the block driver, but it's clearly not whatever > wireshark is using. I'll

Re: [PATCH v4 1/2] timers: Don't wake ktimersoftd on every tick

Hi Mike, I haven't tested the patch with wireshark until now. My system also hangs shortly after it starts. I'm pretty sure I hit workqueues in my earlier tests via the block driver, but it's clearly not whatever wireshark is using. I'll look at it and try to post a fix. CCing the list to avo

[PATCH v4 1/2] timers: Don't wake ktimersoftd on every tick

We recently upgraded from 4.1 to 4.6 and noticed a minor latency regression caused by an additional thread wakeup (ktimersoftd) in interrupt context on every tick. The wakeups are from run_local_timers() raising TIMER_SOFTIRQ. Both TIMER and SCHED softirq coalesced into one ksoftirqd wakeup prior t