2019-06-01 11:08:44 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* linux/kernel/softirq.c
|
|
|
|
*
|
|
|
|
* Copyright (C) 1992 Linus Torvalds
|
|
|
|
*
|
2008-01-30 15:30:00 +03:00
|
|
|
* Rewritten. Old one was good in 2.2, but in 2.3 it was immoral. --ANK (990903)
|
2005-04-17 02:20:36 +04:00
|
|
|
*/
|
|
|
|
|
2014-01-28 05:07:15 +04:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2011-05-23 22:51:41 +04:00
|
|
|
#include <linux/export.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/kernel_stat.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/notifier.h>
|
|
|
|
#include <linux/percpu.h>
|
|
|
|
#include <linux/cpu.h>
|
2007-07-17 15:03:35 +04:00
|
|
|
#include <linux/freezer.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/kthread.h>
|
|
|
|
#include <linux/rcupdate.h>
|
2009-01-23 03:01:40 +03:00
|
|
|
#include <linux/ftrace.h>
|
2006-03-22 11:08:16 +03:00
|
|
|
#include <linux/smp.h>
|
2012-07-16 14:42:37 +04:00
|
|
|
#include <linux/smpboot.h>
|
2007-02-16 12:28:03 +03:00
|
|
|
#include <linux/tick.h>
|
2014-03-19 14:19:52 +04:00
|
|
|
#include <linux/irq.h>
|
2009-04-29 15:51:39 +04:00
|
|
|
|
|
|
|
#define CREATE_TRACE_POINTS
|
2009-04-15 03:39:12 +04:00
|
|
|
#include <trace/events/irq.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
- No shared variables, all the data are CPU local.
|
|
|
|
- If a softirq needs serialization, let it serialize itself
|
|
|
|
by its own spinlocks.
|
|
|
|
- Even if softirq is serialized, only local cpu is marked for
|
|
|
|
execution. Hence, we get something sort of weak cpu binding.
|
|
|
|
Though it is still not clear, will it result in better locality
|
|
|
|
or will not.
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
- NET RX softirq. It is multithreaded and does not require
|
|
|
|
any global serialization.
|
|
|
|
- NET TX softirq. It kicks software netdevice queues, hence
|
|
|
|
it is logically serialized per device, but this serialization
|
|
|
|
is invisible to common code.
|
|
|
|
- Tasklets: serialized wrt itself.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __ARCH_IRQ_STAT
|
2018-05-08 16:38:19 +03:00
|
|
|
DEFINE_PER_CPU_ALIGNED(irq_cpustat_t, irq_stat);
|
|
|
|
EXPORT_PER_CPU_SYMBOL(irq_stat);
|
2005-04-17 02:20:36 +04:00
|
|
|
#endif
|
|
|
|
|
2008-09-06 22:04:36 +04:00
|
|
|
static struct softirq_action softirq_vec[NR_SOFTIRQS] __cacheline_aligned_in_smp;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2010-12-22 04:09:00 +03:00
|
|
|
DEFINE_PER_CPU(struct task_struct *, ksoftirqd);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2014-01-28 05:07:16 +04:00
|
|
|
const char * const softirq_to_name[NR_SOFTIRQS] = {
|
2016-10-10 15:10:51 +03:00
|
|
|
"HI", "TIMER", "NET_TX", "NET_RX", "BLOCK", "IRQ_POLL",
|
rcu: Use softirq to address performance regression
Commit a26ac2455ffcf3(rcu: move TREE_RCU from softirq to kthread)
introduced performance regression. In an AIM7 test, this commit degraded
performance by about 40%.
The commit runs rcu callbacks in a kthread instead of softirq. We observed
high rate of context switch which is caused by this. Out test system has
64 CPUs and HZ is 1000, so we saw more than 64k context switch per second
which is caused by RCU's per-CPU kthread. A trace showed that most of
the time the RCU per-CPU kthread doesn't actually handle any callbacks,
but instead just does a very small amount of work handling grace periods.
This means that RCU's per-CPU kthreads are making the scheduler do quite
a bit of work in order to allow a very small amount of RCU-related
processing to be done.
Alex Shi's analysis determined that this slowdown is due to lock
contention within the scheduler. Unfortunately, as Peter Zijlstra points
out, the scheduler's real-time semantics require global action, which
means that this contention is inherent in real-time scheduling. (Yes,
perhaps someone will come up with a workaround -- otherwise, -rt is not
going to do well on large SMP systems -- but this patch will work around
this issue in the meantime. And "the meantime" might well be forever.)
This patch therefore re-introduces softirq processing to RCU, but only
for core RCU work. RCU callbacks are still executed in kthread context,
so that only a small amount of RCU work runs in softirq context in the
common case. This should minimize ksoftirqd execution, allowing us to
skip boosting of ksoftirqd for CONFIG_RCU_BOOST=y kernels.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Tested-by: "Alex,Shi" <alex.shi@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2011-06-14 09:26:25 +04:00
|
|
|
"TASKLET", "SCHED", "HRTIMER", "RCU"
|
2009-03-12 21:33:36 +03:00
|
|
|
};
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* we cannot loop indefinitely here to avoid userspace starvation,
|
|
|
|
* but we also don't want to introduce a worst case 1/HZ latency
|
|
|
|
* to the pending events, so lets the scheduler to balance
|
|
|
|
* the softirq load for us.
|
|
|
|
*/
|
2009-07-21 01:33:49 +04:00
|
|
|
static void wakeup_softirqd(void)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
/* Interrupts are disabled: no need to stop preemption */
|
2010-12-08 18:22:55 +03:00
|
|
|
struct task_struct *tsk = __this_cpu_read(ksoftirqd);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (tsk && tsk->state != TASK_RUNNING)
|
|
|
|
wake_up_process(tsk);
|
|
|
|
}
|
|
|
|
|
softirq: Let ksoftirqd do its job
A while back, Paolo and Hannes sent an RFC patch adding threaded-able
napi poll loop support : (https://patchwork.ozlabs.org/patch/620657/)
The problem seems to be that softirqs are very aggressive and are often
handled by the current process, even if we are under stress and that
ksoftirqd was scheduled, so that innocent threads would have more chance
to make progress.
This patch makes sure that if ksoftirq is running, we let it
perform the softirq work.
Jonathan Corbet summarized the issue in https://lwn.net/Articles/687617/
Tested:
- NIC receiving traffic handled by CPU 0
- UDP receiver running on CPU 0, using a single UDP socket.
- Incoming flood of UDP packets targeting the UDP socket.
Before the patch, the UDP receiver could almost never get CPU cycles and
could only receive ~2,000 packets per second.
After the patch, CPU cycles are split 50/50 between user application and
ksoftirqd/0, and we can effectively read ~900,000 packets per second,
a huge improvement in DOS situation. (Note that more packets are now
dropped by the NIC itself, since the BH handlers get less CPU cycles to
drain RX ring buffer)
Since the load runs in well identified threads context, an admin can
more easily tune process scheduling parameters if needed.
Reported-by: Paolo Abeni <pabeni@redhat.com>
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: Hannes Frederic Sowa <hannes@redhat.com>
Cc: Jesper Dangaard Brouer <jbrouer@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1472665349.14381.356.camel@edumazet-glaptop3.roam.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-08-31 20:42:29 +03:00
|
|
|
/*
|
|
|
|
* If ksoftirqd is scheduled, we do not want to process pending softirqs
|
Mark HI and TASKLET softirq synchronous
Way back in 4.9, we committed 4cd13c21b207 ("softirq: Let ksoftirqd do
its job"), and ever since we've had small nagging issues with it. For
example, we've had:
1ff688209e2e ("watchdog: core: make sure the watchdog_worker is not deferred")
8d5755b3f77b ("watchdog: softdog: fire watchdog even if softirqs do not get to run")
217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")
all of which worked around some of the effects of that commit.
The DVB people have also complained that the commit causes excessive USB
URB latencies, which seems to be due to the USB code using tasklets to
schedule USB traffic. This seems to be an issue mainly when already
living on the edge, but waiting for ksoftirqd to handle it really does
seem to cause excessive latencies.
Now Hanna Hawa reports that this issue isn't just limited to USB URB and
DVB, but also causes timeout problems for the Marvell SoC team:
"I'm facing kernel panic issue while running raid 5 on sata disks
connected to Macchiatobin (Marvell community board with Armada-8040
SoC with 4 ARMv8 cores of CA72) Raid 5 built with Marvell DMA engine
and async_tx mechanism (ASYNC_TX_DMA [=y]); the DMA driver (mv_xor_v2)
uses a tasklet to clean the done descriptors from the queue"
The latency problem causes a panic:
mv_xor_v2 f0400000.xor: dma_sync_wait: timeout!
Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for transaction
We've discussed simply just reverting the original commit entirely, and
also much more involved solutions (with per-softirq threads etc). This
patch is intentionally stupid and fairly limited, because the issue
still remains, and the other solutions either got sidetracked or had
other issues.
We should probably also consider the timer softirqs to be synchronous
and not be delayed to ksoftirqd (since they were the issue with the
earlier watchdog problems), but that should be done as a separate patch.
This does only the tasklet cases.
Reported-and-tested-by: Hanna Hawa <hannah@marvell.com>
Reported-and-tested-by: Josef Griebichler <griebichler.josef@gmx.at>
Reported-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-01-08 22:51:04 +03:00
|
|
|
* right now. Let ksoftirqd handle this at its own rate, to get fairness,
|
|
|
|
* unless we're doing some of the synchronous softirqs.
|
softirq: Let ksoftirqd do its job
A while back, Paolo and Hannes sent an RFC patch adding threaded-able
napi poll loop support : (https://patchwork.ozlabs.org/patch/620657/)
The problem seems to be that softirqs are very aggressive and are often
handled by the current process, even if we are under stress and that
ksoftirqd was scheduled, so that innocent threads would have more chance
to make progress.
This patch makes sure that if ksoftirq is running, we let it
perform the softirq work.
Jonathan Corbet summarized the issue in https://lwn.net/Articles/687617/
Tested:
- NIC receiving traffic handled by CPU 0
- UDP receiver running on CPU 0, using a single UDP socket.
- Incoming flood of UDP packets targeting the UDP socket.
Before the patch, the UDP receiver could almost never get CPU cycles and
could only receive ~2,000 packets per second.
After the patch, CPU cycles are split 50/50 between user application and
ksoftirqd/0, and we can effectively read ~900,000 packets per second,
a huge improvement in DOS situation. (Note that more packets are now
dropped by the NIC itself, since the BH handlers get less CPU cycles to
drain RX ring buffer)
Since the load runs in well identified threads context, an admin can
more easily tune process scheduling parameters if needed.
Reported-by: Paolo Abeni <pabeni@redhat.com>
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: Hannes Frederic Sowa <hannes@redhat.com>
Cc: Jesper Dangaard Brouer <jbrouer@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1472665349.14381.356.camel@edumazet-glaptop3.roam.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-08-31 20:42:29 +03:00
|
|
|
*/
|
Mark HI and TASKLET softirq synchronous
Way back in 4.9, we committed 4cd13c21b207 ("softirq: Let ksoftirqd do
its job"), and ever since we've had small nagging issues with it. For
example, we've had:
1ff688209e2e ("watchdog: core: make sure the watchdog_worker is not deferred")
8d5755b3f77b ("watchdog: softdog: fire watchdog even if softirqs do not get to run")
217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")
all of which worked around some of the effects of that commit.
The DVB people have also complained that the commit causes excessive USB
URB latencies, which seems to be due to the USB code using tasklets to
schedule USB traffic. This seems to be an issue mainly when already
living on the edge, but waiting for ksoftirqd to handle it really does
seem to cause excessive latencies.
Now Hanna Hawa reports that this issue isn't just limited to USB URB and
DVB, but also causes timeout problems for the Marvell SoC team:
"I'm facing kernel panic issue while running raid 5 on sata disks
connected to Macchiatobin (Marvell community board with Armada-8040
SoC with 4 ARMv8 cores of CA72) Raid 5 built with Marvell DMA engine
and async_tx mechanism (ASYNC_TX_DMA [=y]); the DMA driver (mv_xor_v2)
uses a tasklet to clean the done descriptors from the queue"
The latency problem causes a panic:
mv_xor_v2 f0400000.xor: dma_sync_wait: timeout!
Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for transaction
We've discussed simply just reverting the original commit entirely, and
also much more involved solutions (with per-softirq threads etc). This
patch is intentionally stupid and fairly limited, because the issue
still remains, and the other solutions either got sidetracked or had
other issues.
We should probably also consider the timer softirqs to be synchronous
and not be delayed to ksoftirqd (since they were the issue with the
earlier watchdog problems), but that should be done as a separate patch.
This does only the tasklet cases.
Reported-and-tested-by: Hanna Hawa <hannah@marvell.com>
Reported-and-tested-by: Josef Griebichler <griebichler.josef@gmx.at>
Reported-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-01-08 22:51:04 +03:00
|
|
|
#define SOFTIRQ_NOW_MASK ((1 << HI_SOFTIRQ) | (1 << TASKLET_SOFTIRQ))
|
|
|
|
static bool ksoftirqd_running(unsigned long pending)
|
softirq: Let ksoftirqd do its job
A while back, Paolo and Hannes sent an RFC patch adding threaded-able
napi poll loop support : (https://patchwork.ozlabs.org/patch/620657/)
The problem seems to be that softirqs are very aggressive and are often
handled by the current process, even if we are under stress and that
ksoftirqd was scheduled, so that innocent threads would have more chance
to make progress.
This patch makes sure that if ksoftirq is running, we let it
perform the softirq work.
Jonathan Corbet summarized the issue in https://lwn.net/Articles/687617/
Tested:
- NIC receiving traffic handled by CPU 0
- UDP receiver running on CPU 0, using a single UDP socket.
- Incoming flood of UDP packets targeting the UDP socket.
Before the patch, the UDP receiver could almost never get CPU cycles and
could only receive ~2,000 packets per second.
After the patch, CPU cycles are split 50/50 between user application and
ksoftirqd/0, and we can effectively read ~900,000 packets per second,
a huge improvement in DOS situation. (Note that more packets are now
dropped by the NIC itself, since the BH handlers get less CPU cycles to
drain RX ring buffer)
Since the load runs in well identified threads context, an admin can
more easily tune process scheduling parameters if needed.
Reported-by: Paolo Abeni <pabeni@redhat.com>
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: Hannes Frederic Sowa <hannes@redhat.com>
Cc: Jesper Dangaard Brouer <jbrouer@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1472665349.14381.356.camel@edumazet-glaptop3.roam.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-08-31 20:42:29 +03:00
|
|
|
{
|
|
|
|
struct task_struct *tsk = __this_cpu_read(ksoftirqd);
|
|
|
|
|
Mark HI and TASKLET softirq synchronous
Way back in 4.9, we committed 4cd13c21b207 ("softirq: Let ksoftirqd do
its job"), and ever since we've had small nagging issues with it. For
example, we've had:
1ff688209e2e ("watchdog: core: make sure the watchdog_worker is not deferred")
8d5755b3f77b ("watchdog: softdog: fire watchdog even if softirqs do not get to run")
217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")
all of which worked around some of the effects of that commit.
The DVB people have also complained that the commit causes excessive USB
URB latencies, which seems to be due to the USB code using tasklets to
schedule USB traffic. This seems to be an issue mainly when already
living on the edge, but waiting for ksoftirqd to handle it really does
seem to cause excessive latencies.
Now Hanna Hawa reports that this issue isn't just limited to USB URB and
DVB, but also causes timeout problems for the Marvell SoC team:
"I'm facing kernel panic issue while running raid 5 on sata disks
connected to Macchiatobin (Marvell community board with Armada-8040
SoC with 4 ARMv8 cores of CA72) Raid 5 built with Marvell DMA engine
and async_tx mechanism (ASYNC_TX_DMA [=y]); the DMA driver (mv_xor_v2)
uses a tasklet to clean the done descriptors from the queue"
The latency problem causes a panic:
mv_xor_v2 f0400000.xor: dma_sync_wait: timeout!
Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for transaction
We've discussed simply just reverting the original commit entirely, and
also much more involved solutions (with per-softirq threads etc). This
patch is intentionally stupid and fairly limited, because the issue
still remains, and the other solutions either got sidetracked or had
other issues.
We should probably also consider the timer softirqs to be synchronous
and not be delayed to ksoftirqd (since they were the issue with the
earlier watchdog problems), but that should be done as a separate patch.
This does only the tasklet cases.
Reported-and-tested-by: Hanna Hawa <hannah@marvell.com>
Reported-and-tested-by: Josef Griebichler <griebichler.josef@gmx.at>
Reported-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-01-08 22:51:04 +03:00
|
|
|
if (pending & SOFTIRQ_NOW_MASK)
|
|
|
|
return false;
|
2019-01-29 02:46:25 +03:00
|
|
|
return tsk && (tsk->state == TASK_RUNNING) &&
|
|
|
|
!__kthread_should_park(tsk);
|
softirq: Let ksoftirqd do its job
A while back, Paolo and Hannes sent an RFC patch adding threaded-able
napi poll loop support : (https://patchwork.ozlabs.org/patch/620657/)
The problem seems to be that softirqs are very aggressive and are often
handled by the current process, even if we are under stress and that
ksoftirqd was scheduled, so that innocent threads would have more chance
to make progress.
This patch makes sure that if ksoftirq is running, we let it
perform the softirq work.
Jonathan Corbet summarized the issue in https://lwn.net/Articles/687617/
Tested:
- NIC receiving traffic handled by CPU 0
- UDP receiver running on CPU 0, using a single UDP socket.
- Incoming flood of UDP packets targeting the UDP socket.
Before the patch, the UDP receiver could almost never get CPU cycles and
could only receive ~2,000 packets per second.
After the patch, CPU cycles are split 50/50 between user application and
ksoftirqd/0, and we can effectively read ~900,000 packets per second,
a huge improvement in DOS situation. (Note that more packets are now
dropped by the NIC itself, since the BH handlers get less CPU cycles to
drain RX ring buffer)
Since the load runs in well identified threads context, an admin can
more easily tune process scheduling parameters if needed.
Reported-by: Paolo Abeni <pabeni@redhat.com>
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: Hannes Frederic Sowa <hannes@redhat.com>
Cc: Jesper Dangaard Brouer <jbrouer@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1472665349.14381.356.camel@edumazet-glaptop3.roam.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-08-31 20:42:29 +03:00
|
|
|
}
|
|
|
|
|
2010-10-05 04:03:16 +04:00
|
|
|
/*
|
|
|
|
* preempt_count and SOFTIRQ_OFFSET usage:
|
|
|
|
* - preempt_count is changed by SOFTIRQ_OFFSET on entering or leaving
|
|
|
|
* softirq processing.
|
|
|
|
* - preempt_count is changed by SOFTIRQ_DISABLE_OFFSET (= 2 * SOFTIRQ_OFFSET)
|
|
|
|
* on local_bh_disable or local_bh_enable.
|
|
|
|
* This lets us distinguish between whether we are currently processing
|
|
|
|
* softirq and whether we just have bh disabled.
|
|
|
|
*/
|
|
|
|
|
2006-07-03 11:24:42 +04:00
|
|
|
/*
|
|
|
|
* This one is for softirq.c-internal use,
|
|
|
|
* where hardirqs are disabled legitimately:
|
|
|
|
*/
|
2006-07-30 14:04:02 +04:00
|
|
|
#ifdef CONFIG_TRACE_IRQFLAGS
|
2013-11-19 19:13:38 +04:00
|
|
|
void __local_bh_disable_ip(unsigned long ip, unsigned int cnt)
|
2006-07-03 11:24:42 +04:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
WARN_ON_ONCE(in_irq());
|
|
|
|
|
|
|
|
raw_local_irq_save(flags);
|
2009-01-23 03:01:40 +03:00
|
|
|
/*
|
2013-09-10 14:15:23 +04:00
|
|
|
* The preempt tracer hooks into preempt_count_add and will break
|
2009-01-23 03:01:40 +03:00
|
|
|
* lockdep because it calls back into lockdep after SOFTIRQ_OFFSET
|
|
|
|
* is set and before current->softirq_enabled is cleared.
|
|
|
|
* We must manually increment preempt_count here and manually
|
|
|
|
* call the trace_preempt_off later.
|
|
|
|
*/
|
2013-09-10 14:15:23 +04:00
|
|
|
__preempt_count_add(cnt);
|
2006-07-03 11:24:42 +04:00
|
|
|
/*
|
|
|
|
* Were softirqs turned off above:
|
|
|
|
*/
|
2013-11-19 19:13:38 +04:00
|
|
|
if (softirq_count() == (cnt & SOFTIRQ_MASK))
|
2020-03-20 14:56:41 +03:00
|
|
|
lockdep_softirqs_off(ip);
|
2006-07-03 11:24:42 +04:00
|
|
|
raw_local_irq_restore(flags);
|
2009-01-23 03:01:40 +03:00
|
|
|
|
2015-01-07 12:04:41 +03:00
|
|
|
if (preempt_count() == cnt) {
|
|
|
|
#ifdef CONFIG_DEBUG_PREEMPT
|
2016-02-26 16:54:56 +03:00
|
|
|
current->preempt_disable_ip = get_lock_parent_ip();
|
2015-01-07 12:04:41 +03:00
|
|
|
#endif
|
2016-02-26 16:54:56 +03:00
|
|
|
trace_preempt_off(CALLER_ADDR0, get_lock_parent_ip());
|
2015-01-07 12:04:41 +03:00
|
|
|
}
|
2006-07-03 11:24:42 +04:00
|
|
|
}
|
2013-11-19 19:13:38 +04:00
|
|
|
EXPORT_SYMBOL(__local_bh_disable_ip);
|
2006-07-30 14:04:02 +04:00
|
|
|
#endif /* CONFIG_TRACE_IRQFLAGS */
|
2006-07-03 11:24:42 +04:00
|
|
|
|
2010-10-05 04:03:16 +04:00
|
|
|
static void __local_bh_enable(unsigned int cnt)
|
|
|
|
{
|
2017-11-06 18:01:18 +03:00
|
|
|
lockdep_assert_irqs_disabled();
|
2010-10-05 04:03:16 +04:00
|
|
|
|
2018-06-07 23:11:43 +03:00
|
|
|
if (preempt_count() == cnt)
|
|
|
|
trace_preempt_on(CALLER_ADDR0, get_lock_parent_ip());
|
|
|
|
|
2013-11-19 19:13:38 +04:00
|
|
|
if (softirq_count() == (cnt & SOFTIRQ_MASK))
|
2020-03-20 14:56:41 +03:00
|
|
|
lockdep_softirqs_on(_RET_IP_);
|
2018-06-07 23:11:43 +03:00
|
|
|
|
|
|
|
__preempt_count_sub(cnt);
|
2010-10-05 04:03:16 +04:00
|
|
|
}
|
|
|
|
|
2006-07-03 11:24:42 +04:00
|
|
|
/*
|
2018-03-05 22:29:40 +03:00
|
|
|
* Special-case - softirqs can safely be enabled by __do_softirq(),
|
2006-07-03 11:24:42 +04:00
|
|
|
* without processing still-pending softirqs:
|
|
|
|
*/
|
|
|
|
void _local_bh_enable(void)
|
|
|
|
{
|
2013-09-24 06:11:35 +04:00
|
|
|
WARN_ON_ONCE(in_irq());
|
2010-10-05 04:03:16 +04:00
|
|
|
__local_bh_enable(SOFTIRQ_DISABLE_OFFSET);
|
2006-07-03 11:24:42 +04:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(_local_bh_enable);
|
|
|
|
|
2013-11-19 19:13:38 +04:00
|
|
|
void __local_bh_enable_ip(unsigned long ip, unsigned int cnt)
|
2006-07-03 11:24:42 +04:00
|
|
|
{
|
2017-11-06 18:01:18 +03:00
|
|
|
WARN_ON_ONCE(in_irq());
|
|
|
|
lockdep_assert_irqs_enabled();
|
2006-07-30 14:04:02 +04:00
|
|
|
#ifdef CONFIG_TRACE_IRQFLAGS
|
2008-06-18 11:29:37 +04:00
|
|
|
local_irq_disable();
|
2006-07-30 14:04:02 +04:00
|
|
|
#endif
|
2006-07-03 11:24:42 +04:00
|
|
|
/*
|
|
|
|
* Are softirqs going to be turned on now:
|
|
|
|
*/
|
2010-10-05 04:03:16 +04:00
|
|
|
if (softirq_count() == SOFTIRQ_DISABLE_OFFSET)
|
2020-03-20 14:56:41 +03:00
|
|
|
lockdep_softirqs_on(ip);
|
2006-07-03 11:24:42 +04:00
|
|
|
/*
|
|
|
|
* Keep preemption disabled until we are done with
|
|
|
|
* softirq processing:
|
2014-01-28 05:07:16 +04:00
|
|
|
*/
|
2013-11-19 19:13:38 +04:00
|
|
|
preempt_count_sub(cnt - 1);
|
2006-07-03 11:24:42 +04:00
|
|
|
|
2013-09-05 18:14:00 +04:00
|
|
|
if (unlikely(!in_interrupt() && local_softirq_pending())) {
|
|
|
|
/*
|
|
|
|
* Run softirq if any pending. And do it in its own stack
|
|
|
|
* as we may be calling this deep in a task call stack already.
|
|
|
|
*/
|
2006-07-03 11:24:42 +04:00
|
|
|
do_softirq();
|
2013-09-05 18:14:00 +04:00
|
|
|
}
|
2006-07-03 11:24:42 +04:00
|
|
|
|
2013-09-10 14:15:23 +04:00
|
|
|
preempt_count_dec();
|
2006-07-30 14:04:02 +04:00
|
|
|
#ifdef CONFIG_TRACE_IRQFLAGS
|
2008-06-18 11:29:37 +04:00
|
|
|
local_irq_enable();
|
2006-07-30 14:04:02 +04:00
|
|
|
#endif
|
2006-07-03 11:24:42 +04:00
|
|
|
preempt_check_resched();
|
|
|
|
}
|
2013-11-19 19:13:38 +04:00
|
|
|
EXPORT_SYMBOL(__local_bh_enable_ip);
|
2006-07-03 11:24:42 +04:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
2013-06-07 01:29:49 +04:00
|
|
|
* We restart softirq processing for at most MAX_SOFTIRQ_RESTART times,
|
|
|
|
* but break the loop if need_resched() is set or after 2 ms.
|
|
|
|
* The MAX_SOFTIRQ_TIME provides a nice upper bound in most cases, but in
|
|
|
|
* certain cases, such as stop_machine(), jiffies may cease to
|
|
|
|
* increment and so we need the MAX_SOFTIRQ_RESTART limit as
|
|
|
|
* well to make sure we eventually return from this method.
|
2005-04-17 02:20:36 +04:00
|
|
|
*
|
softirq: reduce latencies
In various network workloads, __do_softirq() latencies can be up
to 20 ms if HZ=1000, and 200 ms if HZ=100.
This is because we iterate 10 times in the softirq dispatcher,
and some actions can consume a lot of cycles.
This patch changes the fallback to ksoftirqd condition to :
- A time limit of 2 ms.
- need_resched() being set on current task
When one of this condition is met, we wakeup ksoftirqd for further
softirq processing if we still have pending softirqs.
Using need_resched() as the only condition can trigger RCU stalls,
as we can keep BH disabled for too long.
I ran several benchmarks and got no significant difference in
throughput, but a very significant reduction of latencies (one order
of magnitude) :
In following bench, 200 antagonist "netperf -t TCP_RR" are started in
background, using all available cpus.
Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC
IRQ (hard+soft)
Before patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=550110.424
MIN_LATENCY=146858
MAX_LATENCY=997109
P50_LATENCY=305000
P90_LATENCY=550000
P99_LATENCY=710000
MEAN_LATENCY=376989.12
STDDEV_LATENCY=184046.92
After patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=40545.492
MIN_LATENCY=9834
MAX_LATENCY=78366
P50_LATENCY=33583
P90_LATENCY=59000
P99_LATENCY=69000
MEAN_LATENCY=38364.67
STDDEV_LATENCY=12865.26
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-01-11 03:26:34 +04:00
|
|
|
* These limits have been established via experimentation.
|
2005-04-17 02:20:36 +04:00
|
|
|
* The two things to balance is latency against fairness -
|
|
|
|
* we want to handle softirqs as soon as possible, but they
|
|
|
|
* should not be able to lock up the box.
|
|
|
|
*/
|
softirq: reduce latencies
In various network workloads, __do_softirq() latencies can be up
to 20 ms if HZ=1000, and 200 ms if HZ=100.
This is because we iterate 10 times in the softirq dispatcher,
and some actions can consume a lot of cycles.
This patch changes the fallback to ksoftirqd condition to :
- A time limit of 2 ms.
- need_resched() being set on current task
When one of this condition is met, we wakeup ksoftirqd for further
softirq processing if we still have pending softirqs.
Using need_resched() as the only condition can trigger RCU stalls,
as we can keep BH disabled for too long.
I ran several benchmarks and got no significant difference in
throughput, but a very significant reduction of latencies (one order
of magnitude) :
In following bench, 200 antagonist "netperf -t TCP_RR" are started in
background, using all available cpus.
Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC
IRQ (hard+soft)
Before patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=550110.424
MIN_LATENCY=146858
MAX_LATENCY=997109
P50_LATENCY=305000
P90_LATENCY=550000
P99_LATENCY=710000
MEAN_LATENCY=376989.12
STDDEV_LATENCY=184046.92
After patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=40545.492
MIN_LATENCY=9834
MAX_LATENCY=78366
P50_LATENCY=33583
P90_LATENCY=59000
P99_LATENCY=69000
MEAN_LATENCY=38364.67
STDDEV_LATENCY=12865.26
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-01-11 03:26:34 +04:00
|
|
|
#define MAX_SOFTIRQ_TIME msecs_to_jiffies(2)
|
2013-06-07 01:29:49 +04:00
|
|
|
#define MAX_SOFTIRQ_RESTART 10
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-11-19 19:42:47 +04:00
|
|
|
#ifdef CONFIG_TRACE_IRQFLAGS
|
|
|
|
/*
|
|
|
|
* When we run softirqs from irq_exit() and thus on the hardirq stack we need
|
|
|
|
* to keep the lockdep irq context tracking as tight as possible in order to
|
|
|
|
* not miss-qualify lock contexts and miss possible deadlocks.
|
|
|
|
*/
|
|
|
|
|
2013-11-20 04:07:34 +04:00
|
|
|
static inline bool lockdep_softirq_start(void)
|
2013-11-19 19:42:47 +04:00
|
|
|
{
|
2013-11-20 04:07:34 +04:00
|
|
|
bool in_hardirq = false;
|
2013-11-19 19:42:47 +04:00
|
|
|
|
2020-03-20 14:56:42 +03:00
|
|
|
if (lockdep_hardirq_context(current)) {
|
2013-11-20 04:07:34 +04:00
|
|
|
in_hardirq = true;
|
2020-03-20 14:56:40 +03:00
|
|
|
lockdep_hardirq_exit();
|
2013-11-20 04:07:34 +04:00
|
|
|
}
|
|
|
|
|
2013-11-19 19:42:47 +04:00
|
|
|
lockdep_softirq_enter();
|
2013-11-20 04:07:34 +04:00
|
|
|
|
|
|
|
return in_hardirq;
|
2013-11-19 19:42:47 +04:00
|
|
|
}
|
|
|
|
|
2013-11-20 04:07:34 +04:00
|
|
|
static inline void lockdep_softirq_end(bool in_hardirq)
|
2013-11-19 19:42:47 +04:00
|
|
|
{
|
|
|
|
lockdep_softirq_exit();
|
2013-11-20 04:07:34 +04:00
|
|
|
|
|
|
|
if (in_hardirq)
|
2020-03-20 14:56:40 +03:00
|
|
|
lockdep_hardirq_enter();
|
2013-11-19 19:42:47 +04:00
|
|
|
}
|
|
|
|
#else
|
2013-11-20 04:07:34 +04:00
|
|
|
static inline bool lockdep_softirq_start(void) { return false; }
|
|
|
|
static inline void lockdep_softirq_end(bool in_hardirq) { }
|
2013-11-19 19:42:47 +04:00
|
|
|
#endif
|
|
|
|
|
2016-03-26 00:22:05 +03:00
|
|
|
asmlinkage __visible void __softirq_entry __do_softirq(void)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
softirq: reduce latencies
In various network workloads, __do_softirq() latencies can be up
to 20 ms if HZ=1000, and 200 ms if HZ=100.
This is because we iterate 10 times in the softirq dispatcher,
and some actions can consume a lot of cycles.
This patch changes the fallback to ksoftirqd condition to :
- A time limit of 2 ms.
- need_resched() being set on current task
When one of this condition is met, we wakeup ksoftirqd for further
softirq processing if we still have pending softirqs.
Using need_resched() as the only condition can trigger RCU stalls,
as we can keep BH disabled for too long.
I ran several benchmarks and got no significant difference in
throughput, but a very significant reduction of latencies (one order
of magnitude) :
In following bench, 200 antagonist "netperf -t TCP_RR" are started in
background, using all available cpus.
Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC
IRQ (hard+soft)
Before patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=550110.424
MIN_LATENCY=146858
MAX_LATENCY=997109
P50_LATENCY=305000
P90_LATENCY=550000
P99_LATENCY=710000
MEAN_LATENCY=376989.12
STDDEV_LATENCY=184046.92
After patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=40545.492
MIN_LATENCY=9834
MAX_LATENCY=78366
P50_LATENCY=33583
P90_LATENCY=59000
P99_LATENCY=69000
MEAN_LATENCY=38364.67
STDDEV_LATENCY=12865.26
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-01-11 03:26:34 +04:00
|
|
|
unsigned long end = jiffies + MAX_SOFTIRQ_TIME;
|
2012-08-01 03:44:07 +04:00
|
|
|
unsigned long old_flags = current->flags;
|
2013-06-07 01:29:49 +04:00
|
|
|
int max_restart = MAX_SOFTIRQ_RESTART;
|
2013-11-19 19:42:47 +04:00
|
|
|
struct softirq_action *h;
|
2013-11-20 04:07:34 +04:00
|
|
|
bool in_hardirq;
|
2013-11-19 19:42:47 +04:00
|
|
|
__u32 pending;
|
2014-01-28 05:07:14 +04:00
|
|
|
int softirq_bit;
|
2012-08-01 03:44:07 +04:00
|
|
|
|
|
|
|
/*
|
2018-10-18 17:21:33 +03:00
|
|
|
* Mask out PF_MEMALLOC as the current task context is borrowed for the
|
|
|
|
* softirq. A softirq handled, such as network RX, might set PF_MEMALLOC
|
|
|
|
* again if the socket is related to swapping.
|
2012-08-01 03:44:07 +04:00
|
|
|
*/
|
|
|
|
current->flags &= ~PF_MEMALLOC;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
pending = local_softirq_pending();
|
2012-12-16 23:00:34 +04:00
|
|
|
account_irq_enter_time(current);
|
2006-07-03 11:25:40 +04:00
|
|
|
|
2013-11-19 19:13:38 +04:00
|
|
|
__local_bh_disable_ip(_RET_IP_, SOFTIRQ_OFFSET);
|
2013-11-20 04:07:34 +04:00
|
|
|
in_hardirq = lockdep_softirq_start();
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
restart:
|
|
|
|
/* Reset the pending bitmask before enabling irqs */
|
2005-09-12 20:49:24 +04:00
|
|
|
set_softirq_pending(0);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2005-07-30 21:22:49 +04:00
|
|
|
local_irq_enable();
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
h = softirq_vec;
|
|
|
|
|
2014-01-28 05:07:14 +04:00
|
|
|
while ((softirq_bit = ffs(pending))) {
|
|
|
|
unsigned int vec_nr;
|
|
|
|
int prev_count;
|
|
|
|
|
|
|
|
h += softirq_bit - 1;
|
|
|
|
|
|
|
|
vec_nr = h - softirq_vec;
|
|
|
|
prev_count = preempt_count();
|
|
|
|
|
|
|
|
kstat_incr_softirqs_this_cpu(vec_nr);
|
|
|
|
|
|
|
|
trace_softirq_entry(vec_nr);
|
|
|
|
h->action(h);
|
|
|
|
trace_softirq_exit(vec_nr);
|
|
|
|
if (unlikely(prev_count != preempt_count())) {
|
2014-01-28 05:07:15 +04:00
|
|
|
pr_err("huh, entered softirq %u %s %p with preempt_count %08x, exited with %08x?\n",
|
2014-01-28 05:07:14 +04:00
|
|
|
vec_nr, softirq_to_name[vec_nr], h->action,
|
|
|
|
prev_count, preempt_count());
|
|
|
|
preempt_count_set(prev_count);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
h++;
|
2014-01-28 05:07:14 +04:00
|
|
|
pending >>= softirq_bit;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2018-06-29 00:45:25 +03:00
|
|
|
if (__this_cpu_read(ksoftirqd) == current)
|
|
|
|
rcu_softirq_qs();
|
2005-07-30 21:22:49 +04:00
|
|
|
local_irq_disable();
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
pending = local_softirq_pending();
|
softirq: reduce latencies
In various network workloads, __do_softirq() latencies can be up
to 20 ms if HZ=1000, and 200 ms if HZ=100.
This is because we iterate 10 times in the softirq dispatcher,
and some actions can consume a lot of cycles.
This patch changes the fallback to ksoftirqd condition to :
- A time limit of 2 ms.
- need_resched() being set on current task
When one of this condition is met, we wakeup ksoftirqd for further
softirq processing if we still have pending softirqs.
Using need_resched() as the only condition can trigger RCU stalls,
as we can keep BH disabled for too long.
I ran several benchmarks and got no significant difference in
throughput, but a very significant reduction of latencies (one order
of magnitude) :
In following bench, 200 antagonist "netperf -t TCP_RR" are started in
background, using all available cpus.
Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC
IRQ (hard+soft)
Before patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=550110.424
MIN_LATENCY=146858
MAX_LATENCY=997109
P50_LATENCY=305000
P90_LATENCY=550000
P99_LATENCY=710000
MEAN_LATENCY=376989.12
STDDEV_LATENCY=184046.92
After patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=40545.492
MIN_LATENCY=9834
MAX_LATENCY=78366
P50_LATENCY=33583
P90_LATENCY=59000
P99_LATENCY=69000
MEAN_LATENCY=38364.67
STDDEV_LATENCY=12865.26
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-01-11 03:26:34 +04:00
|
|
|
if (pending) {
|
2013-06-07 01:29:49 +04:00
|
|
|
if (time_before(jiffies, end) && !need_resched() &&
|
|
|
|
--max_restart)
|
softirq: reduce latencies
In various network workloads, __do_softirq() latencies can be up
to 20 ms if HZ=1000, and 200 ms if HZ=100.
This is because we iterate 10 times in the softirq dispatcher,
and some actions can consume a lot of cycles.
This patch changes the fallback to ksoftirqd condition to :
- A time limit of 2 ms.
- need_resched() being set on current task
When one of this condition is met, we wakeup ksoftirqd for further
softirq processing if we still have pending softirqs.
Using need_resched() as the only condition can trigger RCU stalls,
as we can keep BH disabled for too long.
I ran several benchmarks and got no significant difference in
throughput, but a very significant reduction of latencies (one order
of magnitude) :
In following bench, 200 antagonist "netperf -t TCP_RR" are started in
background, using all available cpus.
Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC
IRQ (hard+soft)
Before patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=550110.424
MIN_LATENCY=146858
MAX_LATENCY=997109
P50_LATENCY=305000
P90_LATENCY=550000
P99_LATENCY=710000
MEAN_LATENCY=376989.12
STDDEV_LATENCY=184046.92
After patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=40545.492
MIN_LATENCY=9834
MAX_LATENCY=78366
P50_LATENCY=33583
P90_LATENCY=59000
P99_LATENCY=69000
MEAN_LATENCY=38364.67
STDDEV_LATENCY=12865.26
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-01-11 03:26:34 +04:00
|
|
|
goto restart;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
wakeup_softirqd();
|
softirq: reduce latencies
In various network workloads, __do_softirq() latencies can be up
to 20 ms if HZ=1000, and 200 ms if HZ=100.
This is because we iterate 10 times in the softirq dispatcher,
and some actions can consume a lot of cycles.
This patch changes the fallback to ksoftirqd condition to :
- A time limit of 2 ms.
- need_resched() being set on current task
When one of this condition is met, we wakeup ksoftirqd for further
softirq processing if we still have pending softirqs.
Using need_resched() as the only condition can trigger RCU stalls,
as we can keep BH disabled for too long.
I ran several benchmarks and got no significant difference in
throughput, but a very significant reduction of latencies (one order
of magnitude) :
In following bench, 200 antagonist "netperf -t TCP_RR" are started in
background, using all available cpus.
Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC
IRQ (hard+soft)
Before patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=550110.424
MIN_LATENCY=146858
MAX_LATENCY=997109
P50_LATENCY=305000
P90_LATENCY=550000
P99_LATENCY=710000
MEAN_LATENCY=376989.12
STDDEV_LATENCY=184046.92
After patch :
# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=40545.492
MIN_LATENCY=9834
MAX_LATENCY=78366
P50_LATENCY=33583
P90_LATENCY=59000
P99_LATENCY=69000
MEAN_LATENCY=38364.67
STDDEV_LATENCY=12865.26
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-01-11 03:26:34 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-11-20 04:07:34 +04:00
|
|
|
lockdep_softirq_end(in_hardirq);
|
2012-12-16 23:00:34 +04:00
|
|
|
account_irq_exit_time(current);
|
2010-10-05 04:03:16 +04:00
|
|
|
__local_bh_enable(SOFTIRQ_OFFSET);
|
2013-09-24 06:11:35 +04:00
|
|
|
WARN_ON_ONCE(in_interrupt());
|
2017-04-07 03:03:26 +03:00
|
|
|
current_restore_flags(old_flags, PF_MEMALLOC);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2014-05-02 02:44:38 +04:00
|
|
|
asmlinkage __visible void do_softirq(void)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
__u32 pending;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
if (in_interrupt())
|
|
|
|
return;
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
|
|
|
|
pending = local_softirq_pending();
|
|
|
|
|
Mark HI and TASKLET softirq synchronous
Way back in 4.9, we committed 4cd13c21b207 ("softirq: Let ksoftirqd do
its job"), and ever since we've had small nagging issues with it. For
example, we've had:
1ff688209e2e ("watchdog: core: make sure the watchdog_worker is not deferred")
8d5755b3f77b ("watchdog: softdog: fire watchdog even if softirqs do not get to run")
217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")
all of which worked around some of the effects of that commit.
The DVB people have also complained that the commit causes excessive USB
URB latencies, which seems to be due to the USB code using tasklets to
schedule USB traffic. This seems to be an issue mainly when already
living on the edge, but waiting for ksoftirqd to handle it really does
seem to cause excessive latencies.
Now Hanna Hawa reports that this issue isn't just limited to USB URB and
DVB, but also causes timeout problems for the Marvell SoC team:
"I'm facing kernel panic issue while running raid 5 on sata disks
connected to Macchiatobin (Marvell community board with Armada-8040
SoC with 4 ARMv8 cores of CA72) Raid 5 built with Marvell DMA engine
and async_tx mechanism (ASYNC_TX_DMA [=y]); the DMA driver (mv_xor_v2)
uses a tasklet to clean the done descriptors from the queue"
The latency problem causes a panic:
mv_xor_v2 f0400000.xor: dma_sync_wait: timeout!
Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for transaction
We've discussed simply just reverting the original commit entirely, and
also much more involved solutions (with per-softirq threads etc). This
patch is intentionally stupid and fairly limited, because the issue
still remains, and the other solutions either got sidetracked or had
other issues.
We should probably also consider the timer softirqs to be synchronous
and not be delayed to ksoftirqd (since they were the issue with the
earlier watchdog problems), but that should be done as a separate patch.
This does only the tasklet cases.
Reported-and-tested-by: Hanna Hawa <hannah@marvell.com>
Reported-and-tested-by: Josef Griebichler <griebichler.josef@gmx.at>
Reported-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-01-08 22:51:04 +03:00
|
|
|
if (pending && !ksoftirqd_running(pending))
|
2013-09-05 17:49:45 +04:00
|
|
|
do_softirq_own_stack();
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
|
2020-05-21 23:05:21 +03:00
|
|
|
/**
|
|
|
|
* irq_enter_rcu - Enter an interrupt context with RCU watching
|
2007-02-16 12:27:45 +03:00
|
|
|
*/
|
2020-05-21 23:05:21 +03:00
|
|
|
void irq_enter_rcu(void)
|
2007-02-16 12:27:45 +03:00
|
|
|
{
|
2012-01-24 21:59:44 +04:00
|
|
|
if (is_idle_task(current) && !in_interrupt()) {
|
2010-10-05 04:03:23 +04:00
|
|
|
/*
|
|
|
|
* Prevent raise_softirq from needlessly waking up ksoftirqd
|
|
|
|
* here, as softirq will be serviced on return from interrupt.
|
|
|
|
*/
|
|
|
|
local_bh_disable();
|
2013-12-04 21:28:20 +04:00
|
|
|
tick_irq_enter();
|
2010-10-05 04:03:23 +04:00
|
|
|
_local_bh_enable();
|
|
|
|
}
|
|
|
|
__irq_enter();
|
2007-02-16 12:27:45 +03:00
|
|
|
}
|
|
|
|
|
2020-05-21 23:05:21 +03:00
|
|
|
/**
|
|
|
|
* irq_enter - Enter an interrupt context including RCU update
|
|
|
|
*/
|
|
|
|
void irq_enter(void)
|
|
|
|
{
|
|
|
|
rcu_irq_enter();
|
|
|
|
irq_enter_rcu();
|
|
|
|
}
|
|
|
|
|
2011-02-24 02:52:23 +03:00
|
|
|
static inline void invoke_softirq(void)
|
|
|
|
{
|
Mark HI and TASKLET softirq synchronous
Way back in 4.9, we committed 4cd13c21b207 ("softirq: Let ksoftirqd do
its job"), and ever since we've had small nagging issues with it. For
example, we've had:
1ff688209e2e ("watchdog: core: make sure the watchdog_worker is not deferred")
8d5755b3f77b ("watchdog: softdog: fire watchdog even if softirqs do not get to run")
217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")
all of which worked around some of the effects of that commit.
The DVB people have also complained that the commit causes excessive USB
URB latencies, which seems to be due to the USB code using tasklets to
schedule USB traffic. This seems to be an issue mainly when already
living on the edge, but waiting for ksoftirqd to handle it really does
seem to cause excessive latencies.
Now Hanna Hawa reports that this issue isn't just limited to USB URB and
DVB, but also causes timeout problems for the Marvell SoC team:
"I'm facing kernel panic issue while running raid 5 on sata disks
connected to Macchiatobin (Marvell community board with Armada-8040
SoC with 4 ARMv8 cores of CA72) Raid 5 built with Marvell DMA engine
and async_tx mechanism (ASYNC_TX_DMA [=y]); the DMA driver (mv_xor_v2)
uses a tasklet to clean the done descriptors from the queue"
The latency problem causes a panic:
mv_xor_v2 f0400000.xor: dma_sync_wait: timeout!
Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for transaction
We've discussed simply just reverting the original commit entirely, and
also much more involved solutions (with per-softirq threads etc). This
patch is intentionally stupid and fairly limited, because the issue
still remains, and the other solutions either got sidetracked or had
other issues.
We should probably also consider the timer softirqs to be synchronous
and not be delayed to ksoftirqd (since they were the issue with the
earlier watchdog problems), but that should be done as a separate patch.
This does only the tasklet cases.
Reported-and-tested-by: Hanna Hawa <hannah@marvell.com>
Reported-and-tested-by: Josef Griebichler <griebichler.josef@gmx.at>
Reported-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-01-08 22:51:04 +03:00
|
|
|
if (ksoftirqd_running(local_softirq_pending()))
|
softirq: Let ksoftirqd do its job
A while back, Paolo and Hannes sent an RFC patch adding threaded-able
napi poll loop support : (https://patchwork.ozlabs.org/patch/620657/)
The problem seems to be that softirqs are very aggressive and are often
handled by the current process, even if we are under stress and that
ksoftirqd was scheduled, so that innocent threads would have more chance
to make progress.
This patch makes sure that if ksoftirq is running, we let it
perform the softirq work.
Jonathan Corbet summarized the issue in https://lwn.net/Articles/687617/
Tested:
- NIC receiving traffic handled by CPU 0
- UDP receiver running on CPU 0, using a single UDP socket.
- Incoming flood of UDP packets targeting the UDP socket.
Before the patch, the UDP receiver could almost never get CPU cycles and
could only receive ~2,000 packets per second.
After the patch, CPU cycles are split 50/50 between user application and
ksoftirqd/0, and we can effectively read ~900,000 packets per second,
a huge improvement in DOS situation. (Note that more packets are now
dropped by the NIC itself, since the BH handlers get less CPU cycles to
drain RX ring buffer)
Since the load runs in well identified threads context, an admin can
more easily tune process scheduling parameters if needed.
Reported-by: Paolo Abeni <pabeni@redhat.com>
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: Hannes Frederic Sowa <hannes@redhat.com>
Cc: Jesper Dangaard Brouer <jbrouer@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1472665349.14381.356.camel@edumazet-glaptop3.roam.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-08-31 20:42:29 +03:00
|
|
|
return;
|
|
|
|
|
2013-09-24 02:50:25 +04:00
|
|
|
if (!force_irqthreads) {
|
2013-09-24 19:17:47 +04:00
|
|
|
#ifdef CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK
|
2013-09-24 02:50:25 +04:00
|
|
|
/*
|
|
|
|
* We can safely execute softirq on the current stack if
|
|
|
|
* it is the irq stack, because it should be near empty
|
2013-09-24 19:17:47 +04:00
|
|
|
* at this stage.
|
|
|
|
*/
|
|
|
|
__do_softirq();
|
|
|
|
#else
|
|
|
|
/*
|
|
|
|
* Otherwise, irq_exit() is called on the task stack that can
|
|
|
|
* be potentially deep already. So call softirq in its own stack
|
|
|
|
* to prevent from any overrun.
|
2013-09-24 02:50:25 +04:00
|
|
|
*/
|
2013-09-24 18:39:41 +04:00
|
|
|
do_softirq_own_stack();
|
2013-09-24 19:17:47 +04:00
|
|
|
#endif
|
2013-09-24 02:50:25 +04:00
|
|
|
} else {
|
2011-02-24 02:52:23 +03:00
|
|
|
wakeup_softirqd();
|
2013-09-24 02:50:25 +04:00
|
|
|
}
|
2011-02-24 02:52:23 +03:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-04-20 19:43:13 +04:00
|
|
|
static inline void tick_irq_exit(void)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_NO_HZ_COMMON
|
|
|
|
int cpu = smp_processor_id();
|
|
|
|
|
|
|
|
/* Make sure that timer wheel updates are propagated */
|
|
|
|
if ((idle_cpu(cpu) && !need_resched()) || tick_nohz_full_cpu(cpu)) {
|
2018-08-03 16:31:34 +03:00
|
|
|
if (!in_irq())
|
2013-04-20 19:43:13 +04:00
|
|
|
tick_nohz_irq_exit();
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2020-05-30 00:27:39 +03:00
|
|
|
static inline void __irq_exit_rcu(void)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-02-21 01:00:48 +04:00
|
|
|
#ifndef __ARCH_IRQ_EXIT_IRQS_DISABLED
|
2013-02-28 23:00:43 +04:00
|
|
|
local_irq_disable();
|
2013-02-21 01:00:48 +04:00
|
|
|
#else
|
2017-11-06 18:01:18 +03:00
|
|
|
lockdep_assert_irqs_disabled();
|
2013-02-21 01:00:48 +04:00
|
|
|
#endif
|
2012-12-16 23:00:34 +04:00
|
|
|
account_irq_exit_time(current);
|
2013-09-10 14:15:23 +04:00
|
|
|
preempt_count_sub(HARDIRQ_OFFSET);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (!in_interrupt() && local_softirq_pending())
|
|
|
|
invoke_softirq();
|
2007-02-16 12:28:03 +03:00
|
|
|
|
2013-04-20 19:43:13 +04:00
|
|
|
tick_irq_exit();
|
2020-05-21 23:05:21 +03:00
|
|
|
}
|
|
|
|
|
2020-05-30 00:27:39 +03:00
|
|
|
/**
|
|
|
|
* irq_exit_rcu() - Exit an interrupt context without updating RCU
|
|
|
|
*
|
|
|
|
* Also processes softirqs if needed and possible.
|
|
|
|
*/
|
|
|
|
void irq_exit_rcu(void)
|
|
|
|
{
|
|
|
|
__irq_exit_rcu();
|
|
|
|
/* must be last! */
|
|
|
|
lockdep_hardirq_exit();
|
|
|
|
}
|
|
|
|
|
2020-05-21 23:05:21 +03:00
|
|
|
/**
|
|
|
|
* irq_exit - Exit an interrupt context, update RCU and lockdep
|
|
|
|
*
|
|
|
|
* Also processes softirqs if needed and possible.
|
|
|
|
*/
|
|
|
|
void irq_exit(void)
|
|
|
|
{
|
2020-05-30 00:27:39 +03:00
|
|
|
__irq_exit_rcu();
|
2011-10-08 03:31:02 +04:00
|
|
|
rcu_irq_exit();
|
2020-03-20 14:56:40 +03:00
|
|
|
/* must be last! */
|
|
|
|
lockdep_hardirq_exit();
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function must run with irqs disabled!
|
|
|
|
*/
|
2008-02-08 15:19:53 +03:00
|
|
|
inline void raise_softirq_irqoff(unsigned int nr)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
__raise_softirq_irqoff(nr);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we're in an interrupt or softirq, we're done
|
|
|
|
* (this also catches softirq-disabled code). We will
|
|
|
|
* actually run the softirq once we return from
|
|
|
|
* the irq or softirq.
|
|
|
|
*
|
|
|
|
* Otherwise we wake up ksoftirqd to make sure we
|
|
|
|
* schedule the softirq soon.
|
|
|
|
*/
|
|
|
|
if (!in_interrupt())
|
|
|
|
wakeup_softirqd();
|
|
|
|
}
|
|
|
|
|
2008-02-08 15:19:53 +03:00
|
|
|
void raise_softirq(unsigned int nr)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
raise_softirq_irqoff(nr);
|
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
|
2012-01-26 05:18:55 +04:00
|
|
|
void __raise_softirq_irqoff(unsigned int nr)
|
|
|
|
{
|
|
|
|
trace_softirq_raise(nr);
|
|
|
|
or_softirq_pending(1UL << nr);
|
|
|
|
}
|
|
|
|
|
Remove argument from open_softirq which is always NULL
As git-grep shows, open_softirq() is always called with the last argument
being NULL
block/blk-core.c: open_softirq(BLOCK_SOFTIRQ, blk_done_softirq, NULL);
kernel/hrtimer.c: open_softirq(HRTIMER_SOFTIRQ, run_hrtimer_softirq, NULL);
kernel/rcuclassic.c: open_softirq(RCU_SOFTIRQ, rcu_process_callbacks, NULL);
kernel/rcupreempt.c: open_softirq(RCU_SOFTIRQ, rcu_process_callbacks, NULL);
kernel/sched.c: open_softirq(SCHED_SOFTIRQ, run_rebalance_domains, NULL);
kernel/softirq.c: open_softirq(TASKLET_SOFTIRQ, tasklet_action, NULL);
kernel/softirq.c: open_softirq(HI_SOFTIRQ, tasklet_hi_action, NULL);
kernel/timer.c: open_softirq(TIMER_SOFTIRQ, run_timer_softirq, NULL);
net/core/dev.c: open_softirq(NET_TX_SOFTIRQ, net_tx_action, NULL);
net/core/dev.c: open_softirq(NET_RX_SOFTIRQ, net_rx_action, NULL);
This observation has already been made by Matthew Wilcox in June 2002
(http://www.cs.helsinki.fi/linux/linux-kernel/2002-25/0687.html)
"I notice that none of the current softirq routines use the data element
passed to them."
and the situation hasn't changed since them. So it appears we can safely
remove that extra argument to save 128 (54) bytes of kernel data (text).
Signed-off-by: Carlos R. Mafra <crmafra@ift.unesp.br>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-15 18:15:37 +04:00
|
|
|
void open_softirq(int nr, void (*action)(struct softirq_action *))
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
softirq_vec[nr].action = action;
|
|
|
|
}
|
|
|
|
|
2009-07-22 16:18:35 +04:00
|
|
|
/*
|
|
|
|
* Tasklets
|
|
|
|
*/
|
2014-01-28 05:07:16 +04:00
|
|
|
struct tasklet_head {
|
2008-03-05 02:23:25 +03:00
|
|
|
struct tasklet_struct *head;
|
|
|
|
struct tasklet_struct **tail;
|
2005-04-17 02:20:36 +04:00
|
|
|
};
|
|
|
|
|
2008-06-13 01:21:53 +04:00
|
|
|
static DEFINE_PER_CPU(struct tasklet_head, tasklet_vec);
|
|
|
|
static DEFINE_PER_CPU(struct tasklet_head, tasklet_hi_vec);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2018-02-27 19:48:07 +03:00
|
|
|
static void __tasklet_schedule_common(struct tasklet_struct *t,
|
|
|
|
struct tasklet_head __percpu *headp,
|
|
|
|
unsigned int softirq_nr)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2018-02-27 19:48:07 +03:00
|
|
|
struct tasklet_head *head;
|
2005-04-17 02:20:36 +04:00
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
2018-02-27 19:48:07 +03:00
|
|
|
head = this_cpu_ptr(headp);
|
2008-03-05 02:23:25 +03:00
|
|
|
t->next = NULL;
|
2018-02-27 19:48:07 +03:00
|
|
|
*head->tail = t;
|
|
|
|
head->tail = &(t->next);
|
|
|
|
raise_softirq_irqoff(softirq_nr);
|
2005-04-17 02:20:36 +04:00
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
2018-02-27 19:48:07 +03:00
|
|
|
|
|
|
|
void __tasklet_schedule(struct tasklet_struct *t)
|
|
|
|
{
|
|
|
|
__tasklet_schedule_common(t, &tasklet_vec,
|
|
|
|
TASKLET_SOFTIRQ);
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
EXPORT_SYMBOL(__tasklet_schedule);
|
|
|
|
|
2008-02-08 15:19:53 +03:00
|
|
|
void __tasklet_hi_schedule(struct tasklet_struct *t)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2018-02-27 19:48:07 +03:00
|
|
|
__tasklet_schedule_common(t, &tasklet_hi_vec,
|
|
|
|
HI_SOFTIRQ);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__tasklet_hi_schedule);
|
|
|
|
|
2018-02-27 19:48:08 +03:00
|
|
|
static void tasklet_action_common(struct softirq_action *a,
|
|
|
|
struct tasklet_head *tl_head,
|
|
|
|
unsigned int softirq_nr)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
struct tasklet_struct *list;
|
|
|
|
|
|
|
|
local_irq_disable();
|
2018-02-27 19:48:08 +03:00
|
|
|
list = tl_head->head;
|
|
|
|
tl_head->head = NULL;
|
|
|
|
tl_head->tail = &tl_head->head;
|
2005-04-17 02:20:36 +04:00
|
|
|
local_irq_enable();
|
|
|
|
|
|
|
|
while (list) {
|
|
|
|
struct tasklet_struct *t = list;
|
|
|
|
|
|
|
|
list = list->next;
|
|
|
|
|
|
|
|
if (tasklet_trylock(t)) {
|
|
|
|
if (!atomic_read(&t->count)) {
|
2014-01-28 05:07:16 +04:00
|
|
|
if (!test_and_clear_bit(TASKLET_STATE_SCHED,
|
|
|
|
&t->state))
|
2005-04-17 02:20:36 +04:00
|
|
|
BUG();
|
|
|
|
t->func(t->data);
|
|
|
|
tasklet_unlock(t);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
tasklet_unlock(t);
|
|
|
|
}
|
|
|
|
|
|
|
|
local_irq_disable();
|
2008-03-05 02:23:25 +03:00
|
|
|
t->next = NULL;
|
2018-02-27 19:48:08 +03:00
|
|
|
*tl_head->tail = t;
|
|
|
|
tl_head->tail = &t->next;
|
|
|
|
__raise_softirq_irqoff(softirq_nr);
|
2005-04-17 02:20:36 +04:00
|
|
|
local_irq_enable();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-27 19:48:08 +03:00
|
|
|
static __latent_entropy void tasklet_action(struct softirq_action *a)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2018-02-27 19:48:08 +03:00
|
|
|
tasklet_action_common(a, this_cpu_ptr(&tasklet_vec), TASKLET_SOFTIRQ);
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2018-02-27 19:48:08 +03:00
|
|
|
static __latent_entropy void tasklet_hi_action(struct softirq_action *a)
|
|
|
|
{
|
|
|
|
tasklet_action_common(a, this_cpu_ptr(&tasklet_hi_vec), HI_SOFTIRQ);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void tasklet_init(struct tasklet_struct *t,
|
|
|
|
void (*func)(unsigned long), unsigned long data)
|
|
|
|
{
|
|
|
|
t->next = NULL;
|
|
|
|
t->state = 0;
|
|
|
|
atomic_set(&t->count, 0);
|
|
|
|
t->func = func;
|
|
|
|
t->data = data;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(tasklet_init);
|
|
|
|
|
|
|
|
void tasklet_kill(struct tasklet_struct *t)
|
|
|
|
{
|
|
|
|
if (in_interrupt())
|
2014-01-28 05:07:15 +04:00
|
|
|
pr_notice("Attempt to kill tasklet from interrupt\n");
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
while (test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) {
|
2009-04-17 03:30:18 +04:00
|
|
|
do {
|
2005-04-17 02:20:36 +04:00
|
|
|
yield();
|
2009-04-17 03:30:18 +04:00
|
|
|
} while (test_bit(TASKLET_STATE_SCHED, &t->state));
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
tasklet_unlock_wait(t);
|
|
|
|
clear_bit(TASKLET_STATE_SCHED, &t->state);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(tasklet_kill);
|
|
|
|
|
|
|
|
void __init softirq_init(void)
|
|
|
|
{
|
2008-03-05 02:23:25 +03:00
|
|
|
int cpu;
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
per_cpu(tasklet_vec, cpu).tail =
|
|
|
|
&per_cpu(tasklet_vec, cpu).head;
|
|
|
|
per_cpu(tasklet_hi_vec, cpu).tail =
|
|
|
|
&per_cpu(tasklet_hi_vec, cpu).head;
|
|
|
|
}
|
|
|
|
|
Remove argument from open_softirq which is always NULL
As git-grep shows, open_softirq() is always called with the last argument
being NULL
block/blk-core.c: open_softirq(BLOCK_SOFTIRQ, blk_done_softirq, NULL);
kernel/hrtimer.c: open_softirq(HRTIMER_SOFTIRQ, run_hrtimer_softirq, NULL);
kernel/rcuclassic.c: open_softirq(RCU_SOFTIRQ, rcu_process_callbacks, NULL);
kernel/rcupreempt.c: open_softirq(RCU_SOFTIRQ, rcu_process_callbacks, NULL);
kernel/sched.c: open_softirq(SCHED_SOFTIRQ, run_rebalance_domains, NULL);
kernel/softirq.c: open_softirq(TASKLET_SOFTIRQ, tasklet_action, NULL);
kernel/softirq.c: open_softirq(HI_SOFTIRQ, tasklet_hi_action, NULL);
kernel/timer.c: open_softirq(TIMER_SOFTIRQ, run_timer_softirq, NULL);
net/core/dev.c: open_softirq(NET_TX_SOFTIRQ, net_tx_action, NULL);
net/core/dev.c: open_softirq(NET_RX_SOFTIRQ, net_rx_action, NULL);
This observation has already been made by Matthew Wilcox in June 2002
(http://www.cs.helsinki.fi/linux/linux-kernel/2002-25/0687.html)
"I notice that none of the current softirq routines use the data element
passed to them."
and the situation hasn't changed since them. So it appears we can safely
remove that extra argument to save 128 (54) bytes of kernel data (text).
Signed-off-by: Carlos R. Mafra <crmafra@ift.unesp.br>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-15 18:15:37 +04:00
|
|
|
open_softirq(TASKLET_SOFTIRQ, tasklet_action);
|
|
|
|
open_softirq(HI_SOFTIRQ, tasklet_hi_action);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2012-07-16 14:42:37 +04:00
|
|
|
static int ksoftirqd_should_run(unsigned int cpu)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2012-07-16 14:42:37 +04:00
|
|
|
return local_softirq_pending();
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2012-07-16 14:42:37 +04:00
|
|
|
static void run_ksoftirqd(unsigned int cpu)
|
|
|
|
{
|
|
|
|
local_irq_disable();
|
|
|
|
if (local_softirq_pending()) {
|
2013-09-05 18:14:00 +04:00
|
|
|
/*
|
|
|
|
* We can safely run softirq on inline stack, as we are not deep
|
|
|
|
* in the task stack here.
|
|
|
|
*/
|
2012-07-16 14:42:37 +04:00
|
|
|
__do_softirq();
|
|
|
|
local_irq_enable();
|
2017-10-24 18:31:12 +03:00
|
|
|
cond_resched();
|
2012-07-16 14:42:37 +04:00
|
|
|
return;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
2012-07-16 14:42:37 +04:00
|
|
|
local_irq_enable();
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_HOTPLUG_CPU
|
|
|
|
/*
|
|
|
|
* tasklet_kill_immediate is called to remove a tasklet which can already be
|
|
|
|
* scheduled for execution on @cpu.
|
|
|
|
*
|
|
|
|
* Unlike tasklet_kill, this function removes the tasklet
|
|
|
|
* _immediately_, even if the tasklet is in TASKLET_STATE_SCHED state.
|
|
|
|
*
|
|
|
|
* When this function is called, @cpu must be in the CPU_DEAD state.
|
|
|
|
*/
|
|
|
|
void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu)
|
|
|
|
{
|
|
|
|
struct tasklet_struct **i;
|
|
|
|
|
|
|
|
BUG_ON(cpu_online(cpu));
|
|
|
|
BUG_ON(test_bit(TASKLET_STATE_RUN, &t->state));
|
|
|
|
|
|
|
|
if (!test_bit(TASKLET_STATE_SCHED, &t->state))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* CPU is dead, so no lock needed. */
|
2008-03-05 02:23:25 +03:00
|
|
|
for (i = &per_cpu(tasklet_vec, cpu).head; *i; i = &(*i)->next) {
|
2005-04-17 02:20:36 +04:00
|
|
|
if (*i == t) {
|
|
|
|
*i = t->next;
|
2008-03-05 02:23:25 +03:00
|
|
|
/* If this was the tail element, move the tail ptr */
|
|
|
|
if (*i == NULL)
|
|
|
|
per_cpu(tasklet_vec, cpu).tail = i;
|
2005-04-17 02:20:36 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
2016-08-18 15:57:21 +03:00
|
|
|
static int takeover_tasklets(unsigned int cpu)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
/* CPU is dead, so no lock needed. */
|
|
|
|
local_irq_disable();
|
|
|
|
|
|
|
|
/* Find end, append list for that CPU. */
|
2008-05-01 15:34:23 +04:00
|
|
|
if (&per_cpu(tasklet_vec, cpu).head != per_cpu(tasklet_vec, cpu).tail) {
|
2010-12-08 18:22:55 +03:00
|
|
|
*__this_cpu_read(tasklet_vec.tail) = per_cpu(tasklet_vec, cpu).head;
|
2019-06-18 17:33:05 +03:00
|
|
|
__this_cpu_write(tasklet_vec.tail, per_cpu(tasklet_vec, cpu).tail);
|
2008-05-01 15:34:23 +04:00
|
|
|
per_cpu(tasklet_vec, cpu).head = NULL;
|
|
|
|
per_cpu(tasklet_vec, cpu).tail = &per_cpu(tasklet_vec, cpu).head;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
raise_softirq_irqoff(TASKLET_SOFTIRQ);
|
|
|
|
|
2008-05-01 15:34:23 +04:00
|
|
|
if (&per_cpu(tasklet_hi_vec, cpu).head != per_cpu(tasklet_hi_vec, cpu).tail) {
|
2010-12-08 18:22:55 +03:00
|
|
|
*__this_cpu_read(tasklet_hi_vec.tail) = per_cpu(tasklet_hi_vec, cpu).head;
|
|
|
|
__this_cpu_write(tasklet_hi_vec.tail, per_cpu(tasklet_hi_vec, cpu).tail);
|
2008-05-01 15:34:23 +04:00
|
|
|
per_cpu(tasklet_hi_vec, cpu).head = NULL;
|
|
|
|
per_cpu(tasklet_hi_vec, cpu).tail = &per_cpu(tasklet_hi_vec, cpu).head;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
raise_softirq_irqoff(HI_SOFTIRQ);
|
|
|
|
|
|
|
|
local_irq_enable();
|
2016-08-18 15:57:21 +03:00
|
|
|
return 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
2016-08-18 15:57:21 +03:00
|
|
|
#else
|
|
|
|
#define takeover_tasklets NULL
|
2005-04-17 02:20:36 +04:00
|
|
|
#endif /* CONFIG_HOTPLUG_CPU */
|
|
|
|
|
2012-07-16 14:42:37 +04:00
|
|
|
static struct smp_hotplug_thread softirq_threads = {
|
|
|
|
.store = &ksoftirqd,
|
|
|
|
.thread_should_run = ksoftirqd_should_run,
|
|
|
|
.thread_fn = run_ksoftirqd,
|
|
|
|
.thread_comm = "ksoftirqd/%u",
|
|
|
|
};
|
|
|
|
|
2008-07-26 06:45:11 +04:00
|
|
|
static __init int spawn_ksoftirqd(void)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2016-08-18 15:57:21 +03:00
|
|
|
cpuhp_setup_state_nocalls(CPUHP_SOFTIRQ_DEAD, "softirq:dead", NULL,
|
|
|
|
takeover_tasklets);
|
2012-07-16 14:42:37 +04:00
|
|
|
BUG_ON(smpboot_register_percpu_thread(&softirq_threads));
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
|
|
|
}
|
2008-07-26 06:45:11 +04:00
|
|
|
early_initcall(spawn_ksoftirqd);
|
2006-03-22 11:08:16 +03:00
|
|
|
|
2008-12-29 03:01:13 +03:00
|
|
|
/*
|
|
|
|
* [ These __weak aliases are kept in a separate compilation unit, so that
|
|
|
|
* GCC does not inline them incorrectly. ]
|
|
|
|
*/
|
|
|
|
|
|
|
|
int __init __weak early_irq_init(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-01-13 04:39:24 +03:00
|
|
|
int __init __weak arch_probe_nr_irqs(void)
|
|
|
|
{
|
2010-09-27 22:55:03 +04:00
|
|
|
return NR_IRQS_LEGACY;
|
2009-01-13 04:39:24 +03:00
|
|
|
}
|
|
|
|
|
2008-12-29 03:01:13 +03:00
|
|
|
int __init __weak arch_early_irq_init(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2014-04-24 11:50:53 +04:00
|
|
|
|
|
|
|
unsigned int __weak arch_dynirq_lower_bound(unsigned int from)
|
|
|
|
{
|
|
|
|
return from;
|
|
|
|
}
|