From: Eric Dumazet <eric.dumazet@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Rui Xiang <rui.xiang@huawei.com>, Tejun Heo <tj@kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>,
"David S. Miller" <davem@davemloft.net>,
Li Zefan <lizefan@huawei.com>, stable <stable@vger.kernel.org>,
Ben Greear <greearb@candelatech.com>
Subject: Re: [PATCH 2/2] Fix lockup related to stop_machine being stuck in __do_softirq.
Date: Mon, 18 May 2015 13:34:36 -0700 [thread overview]
Message-ID: <1431981276.621.44.camel@edumazet-glaptop2.roam.corp.google.com> (raw)
In-Reply-To: <CA+55aFxM9bOyOBN2diEYL3jS8a7ZxrSpO3_c1umr2KW4+NXkqQ@mail.gmail.com>
On Mon, 2015-05-18 at 12:19 -0700, Linus Torvalds wrote:
> So this one kind of fell through the cracks, partly because I don't
> exactly love the patch.
>
> What is it that keeps re-arming the softirq pending bit all the time?
> You mention the ath9k driver..
>
> Also, do we really need the jiffies-based one at all? Maybe we should
> just get rid of that entirely, if it's not sufficiently reliable
> anyway. It's not like we should *ever* keep doing softirq's forever,
> and quite frankly, when you introduce the limit of doing the loop at
> most ten times, I doubt that the "2 milliseconds" limit is even
> relevant any more. It would be a strange situation where ten times
> through the softirq handling loop would take more than 2ms.
We've seen very often this taking more than 50ms here.
Things get better, but back in 2013, timer handlers could run for quite
a long time. The infamous one is scheduled to me removed for 4.1 (TCP
SYNACK retransmit timer)
next prev parent reply other threads:[~2015-05-18 20:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 6:29 [request for stable inclusion] softirq: reduce latencies Rui Xiang
2015-05-14 6:29 ` [PATCH 1/2] " Rui Xiang
2015-05-14 6:29 ` [PATCH 2/2] Fix lockup related to stop_machine being stuck in __do_softirq Rui Xiang
2015-05-18 19:19 ` Linus Torvalds
2015-05-18 19:41 ` Ben Greear
2015-05-18 19:44 ` Linus Torvalds
2015-05-18 20:34 ` Eric Dumazet [this message]
2015-05-18 21:05 ` David Miller
2015-06-15 3:25 ` [request for stable inclusion] softirq: reduce latencies Zefan Li
2015-08-01 20:59 ` Ben Hutchings
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1431981276.621.44.camel@edumazet-glaptop2.roam.corp.google.com \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=greearb@candelatech.com \
--cc=lizefan@huawei.com \
--cc=rui.xiang@huawei.com \
--cc=rusty@rustcorp.com.au \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.