From: Thomas Gleixner <tglx@linutronix.de>
To: Jason Xing <kerneljasonxing@gmail.com>, Liu Jian <liujian56@huawei.com>
Cc: corbet@lwn.net, paulmck@kernel.org, frederic@kernel.org,
quic_neeraju@quicinc.com, joel@joelfernandes.org,
josh@joshtriplett.org, boqun.feng@gmail.com, rostedt@goodmis.org,
mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com,
qiang1.zhang@intel.com, jstultz@google.com, sboyd@kernel.org,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, peterz@infradead.org, frankwoo@google.com,
Rhinewuwu@google.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH 2/9] softirq: Use sched_clock() based timeout
Date: Mon, 08 May 2023 19:51:41 +0200 [thread overview]
Message-ID: <87cz3a3e4y.ffs@tglx> (raw)
In-Reply-To: <CAL+tcoDY11sSO8_h1DKCWgAXOjQwM1JR5cx7cpmotWVj28m_fg@mail.gmail.com>
On Mon, May 08 2023 at 12:08, Jason Xing wrote:
> On Fri, May 5, 2023 at 7:25 PM Liu Jian <liujian56@huawei.com> wrote:
>> @@ -489,7 +490,7 @@ asmlinkage __visible void do_softirq(void)
>> * we want to handle softirqs as soon as possible, but they
>> * should not be able to lock up the box.
>> */
>> -#define MAX_SOFTIRQ_TIME msecs_to_jiffies(2)
>> +#define MAX_SOFTIRQ_TIME (2 * NSEC_PER_MSEC)
>
> I wonder if it affects those servers that set HZ to some different
> values rather than 1000 as default.
The result of msecs_to_jiffies(2) for different HZ values:
HZ=100 1
HZ=250 1
HZ=1000 2
So depending on when the softirq processing starts, this gives the
following ranges in which the timeout ends:
HZ=100 0 - 10ms
HZ=250 0 - 4ms
HZ=1000 1 - 2ms
But as the various softirq handlers have their own notion of timeouts,
loop limits etc. and the timeout is only checked after _all_ pending
bits of each iteration have been processed, the outcome of this is all
lottery.
Due to that the sched_clock() change per se won't have too much impact,
but if the overall changes to consolidate the break conditions are in
place, I think it will have observable effects.
Making this consistent is definitely a good thing, but it won't solve
the underlying problem of soft interrupt processing at all.
We definitely need to spend more thoughts on pulling things out of soft
interrupt context so that these functionalities get under proper
resource control by the scheduler.
Thanks,
tglx
next prev parent reply other threads:[~2023-05-08 17:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-05 11:33 [PATCH 0/9] fix softlockup in run_timer_softirq Liu Jian
2023-05-05 11:33 ` [PATCH 1/9] softirq: Rewrite softirq processing loop Liu Jian
2023-05-05 11:33 ` [PATCH 2/9] softirq: Use sched_clock() based timeout Liu Jian
2023-05-08 4:08 ` Jason Xing
2023-05-08 17:51 ` Thomas Gleixner [this message]
2023-05-05 11:33 ` [PATCH 3/9] softirq: Factor loop termination condition Liu Jian
2023-05-05 11:33 ` [PATCH 4/9] softirq: Allow early break Liu Jian
2023-05-05 12:10 ` Eric Dumazet
2023-05-08 3:37 ` liujian (CE)
2023-05-05 11:33 ` [PATCH 5/9] softirq: Context aware timeout Liu Jian
2023-05-05 11:33 ` [PATCH 6/9] softirq: Provide a softirq_needs_break() API Liu Jian
2023-05-05 11:33 ` [PATCH 7/9] softirq,net: Use softirq_needs_break() Liu Jian
2023-05-08 6:21 ` Jason Xing
2023-05-05 11:33 ` [PATCH 8/9] softirq,rcu: " Liu Jian
2023-05-05 11:33 ` [PATCH 9/9] softirq, timer: " Liu Jian
[not found] ` <20230505135553.4248-1-hdanton@sina.com>
2023-05-08 3:51 ` liujian (CE)
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=87cz3a3e4y.ffs@tglx \
--to=tglx@linutronix.de \
--cc=Rhinewuwu@google.com \
--cc=boqun.feng@gmail.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=frankwoo@google.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=jstultz@google.com \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liujian56@huawei.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=qiang1.zhang@intel.com \
--cc=quic_neeraju@quicinc.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=sboyd@kernel.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.