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
* Distribute under GPLv2 .
*
* 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 ;
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 tsk & & ( tsk - > state = = TASK_RUNNING ) ;
}
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 ) )
2006-07-03 11:24:42 +04:00
trace_softirqs_off ( ip ) ;
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 ) )
2013-04-30 22:46:09 +04:00
trace_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 )
2008-06-18 11:29:37 +04:00
trace_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
2013-11-20 04:07:34 +04:00
if ( trace_hardirq_context ( current ) ) {
in_hardirq = true ;
2013-11-19 19:42:47 +04:00
trace_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 )
2013-11-19 19:42:47 +04:00
trace_hardirq_enter ( ) ;
}
# 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
/*
* Mask out PF_MEMALLOC s 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 swap
*/
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
2014-08-15 03:38:46 +04:00
rcu_bh_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 ) ;
}
2007-02-16 12:27:45 +03:00
/*
* Enter an interrupt context .
*/
void irq_enter ( void )
{
"Tree RCU": scalable classic RCU implementation
This patch fixes a long-standing performance bug in classic RCU that
results in massive internal-to-RCU lock contention on systems with
more than a few hundred CPUs. Although this patch creates a separate
flavor of RCU for ease of review and patch maintenance, it is intended
to replace classic RCU.
This patch still handles stress better than does mainline, so I am still
calling it ready for inclusion. This patch is against the -tip tree.
Nevertheless, experience on an actual 1000+ CPU machine would still be
most welcome.
Most of the changes noted below were found while creating an rcutiny
(which should permit ejecting the current rcuclassic) and while doing
detailed line-by-line documentation.
Updates from v9 (http://lkml.org/lkml/2008/12/2/334):
o Fixes from remainder of line-by-line code walkthrough,
including comment spelling, initialization, undesirable
narrowing due to type conversion, removing redundant memory
barriers, removing redundant local-variable initialization,
and removing redundant local variables.
I do not believe that any of these fixes address the CPU-hotplug
issues that Andi Kleen was seeing, but please do give it a whirl
in case the machine is smarter than I am.
A writeup from the walkthrough may be found at the following
URL, in case you are suffering from terminal insomnia or
masochism:
http://www.kernel.org/pub/linux/kernel/people/paulmck/tmp/rcutree-walkthrough.2008.12.16a.pdf
o Made rcutree tracing use seq_file, as suggested some time
ago by Lai Jiangshan.
o Added a .csv variant of the rcudata debugfs trace file, to allow
people having thousands of CPUs to drop the data into
a spreadsheet. Tested with oocalc and gnumeric. Updated
documentation to suit.
Updates from v8 (http://lkml.org/lkml/2008/11/15/139):
o Fix a theoretical race between grace-period initialization and
force_quiescent_state() that could occur if more than three
jiffies were required to carry out the grace-period
initialization. Which it might, if you had enough CPUs.
o Apply Ingo's printk-standardization patch.
o Substitute local variables for repeated accesses to global
variables.
o Fix comment misspellings and redundant (but harmless) increments
of ->n_rcu_pending (this latter after having explicitly added it).
o Apply checkpatch fixes.
Updates from v7 (http://lkml.org/lkml/2008/10/10/291):
o Fixed a number of problems noted by Gautham Shenoy, including
the cpu-stall-detection bug that he was having difficulty
convincing me was real. ;-)
o Changed cpu-stall detection to wait for ten seconds rather than
three in order to reduce false positive, as suggested by Ingo
Molnar.
o Produced a design document (http://lwn.net/Articles/305782/).
The act of writing this document uncovered a number of both
theoretical and "here and now" bugs as noted below.
o Fix dynticks_nesting accounting confusion, simplify WARN_ON()
condition, fix kerneldoc comments, and add memory barriers
in dynticks interface functions.
o Add more data to tracing.
o Remove unused "rcu_barrier" field from rcu_data structure.
o Count calls to rcu_pending() from scheduling-clock interrupt
to use as a surrogate timebase should jiffies stop counting.
o Fix a theoretical race between force_quiescent_state() and
grace-period initialization. Yes, initialization does have to
go on for some jiffies for this race to occur, but given enough
CPUs...
Updates from v6 (http://lkml.org/lkml/2008/9/23/448):
o Fix a number of checkpatch.pl complaints.
o Apply review comments from Ingo Molnar and Lai Jiangshan
on the stall-detection code.
o Fix several bugs in !CONFIG_SMP builds.
o Fix a misspelled config-parameter name so that RCU now announces
at boot time if stall detection is configured.
o Run tests on numerous combinations of configurations parameters,
which after the fixes above, now build and run correctly.
Updates from v5 (http://lkml.org/lkml/2008/9/15/92, bad subject line):
o Fix a compiler error in the !CONFIG_FANOUT_EXACT case (blew a
changeset some time ago, and finally got around to retesting
this option).
o Fix some tracing bugs in rcupreempt that caused incorrect
totals to be printed.
o I now test with a more brutal random-selection online/offline
script (attached). Probably more brutal than it needs to be
on the people reading it as well, but so it goes.
o A number of optimizations and usability improvements:
o Make rcu_pending() ignore the grace-period timeout when
there is no grace period in progress.
o Make force_quiescent_state() avoid going for a global
lock in the case where there is no grace period in
progress.
o Rearrange struct fields to improve struct layout.
o Make call_rcu() initiate a grace period if RCU was
idle, rather than waiting for the next scheduling
clock interrupt.
o Invoke rcu_irq_enter() and rcu_irq_exit() only when
idle, as suggested by Andi Kleen. I still don't
completely trust this change, and might back it out.
o Make CONFIG_RCU_TRACE be the single config variable
manipulated for all forms of RCU, instead of the prior
confusion.
o Document tracing files and formats for both rcupreempt
and rcutree.
Updates from v4 for those missing v5 given its bad subject line:
o Separated dynticks interface so that NMIs and irqs call separate
functions, greatly simplifying it. In particular, this code
no longer requires a proof of correctness. ;-)
o Separated dynticks state out into its own per-CPU structure,
avoiding the duplicated accounting.
o The case where a dynticks-idle CPU runs an irq handler that
invokes call_rcu() is now correctly handled, forcing that CPU
out of dynticks-idle mode.
o Review comments have been applied (thank you all!!!).
For but one example, fixed the dynticks-ordering issue that
Manfred pointed out, saving me much debugging. ;-)
o Adjusted rcuclassic and rcupreempt to handle dynticks changes.
Attached is an updated patch to Classic RCU that applies a hierarchy,
greatly reducing the contention on the top-level lock for large machines.
This passes 10-hour concurrent rcutorture and online-offline testing on
128-CPU ppc64 without dynticks enabled, and exposes some timekeeping
bugs in presence of dynticks (exciting working on a system where
"sleep 1" hangs until interrupted...), which were fixed in the
2.6.27 kernel. It is getting more reliable than mainline by some
measures, so the next version will be against -tip for inclusion.
See also Manfred Spraul's recent patches (or his earlier work from
2004 at http://marc.info/?l=linux-kernel&m=108546384711797&w=2).
We will converge onto a common patch in the fullness of time, but are
currently exploring different regions of the design space. That said,
I have already gratefully stolen quite a few of Manfred's ideas.
This patch provides CONFIG_RCU_FANOUT, which controls the bushiness
of the RCU hierarchy. Defaults to 32 on 32-bit machines and 64 on
64-bit machines. If CONFIG_NR_CPUS is less than CONFIG_RCU_FANOUT,
there is no hierarchy. By default, the RCU initialization code will
adjust CONFIG_RCU_FANOUT to balance the hierarchy, so strongly NUMA
architectures may choose to set CONFIG_RCU_FANOUT_EXACT to disable
this balancing, allowing the hierarchy to be exactly aligned to the
underlying hardware. Up to two levels of hierarchy are permitted
(in addition to the root node), allowing up to 16,384 CPUs on 32-bit
systems and up to 262,144 CPUs on 64-bit systems. I just know that I
am going to regret saying this, but this seems more than sufficient
for the foreseeable future. (Some architectures might wish to set
CONFIG_RCU_FANOUT=4, which would limit such architectures to 64 CPUs.
If this becomes a real problem, additional levels can be added, but I
doubt that it will make a significant difference on real hardware.)
In the common case, a given CPU will manipulate its private rcu_data
structure and the rcu_node structure that it shares with its immediate
neighbors. This can reduce both lock and memory contention by multiple
orders of magnitude, which should eliminate the need for the strange
manipulations that are reported to be required when running Linux on
very large systems.
Some shortcomings:
o More bugs will probably surface as a result of an ongoing
line-by-line code inspection.
Patches will be provided as required.
o There are probably hangs, rcutorture failures, &c. Seems
quite stable on a 128-CPU machine, but that is kind of small
compared to 4096 CPUs. However, seems to do better than
mainline.
Patches will be provided as required.
o The memory footprint of this version is several KB larger
than rcuclassic.
A separate UP-only rcutiny patch will be provided, which will
reduce the memory footprint significantly, even compared
to the old rcuclassic. One such patch passes light testing,
and has a memory footprint smaller even than rcuclassic.
Initial reaction from various embedded guys was "it is not
worth it", so am putting it aside.
Credits:
o Manfred Spraul for ideas, review comments, and bugs spotted,
as well as some good friendly competition. ;-)
o Josh Triplett, Ingo Molnar, Peter Zijlstra, Mathieu Desnoyers,
Lai Jiangshan, Andi Kleen, Andy Whitcroft, and Andrew Morton
for reviews and comments.
o Thomas Gleixner for much-needed help with some timer issues
(see patches below).
o Jon M. Tollefson, Tim Pepper, Andrew Theurer, Jose R. Santos,
Andy Whitcroft, Darrick Wong, Nishanth Aravamudan, Anton
Blanchard, Dave Kleikamp, and Nathan Lynch for keeping machines
alive despite my heavy abuse^Wtesting.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-18 23:55:32 +03:00
rcu_irq_enter ( ) ;
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
}
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
}
2005-04-17 02:20:36 +04:00
/*
* Exit an interrupt context . Process softirqs if needed and possible :
*/
void irq_exit ( void )
{
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 ( ) ;
2011-10-08 03:31:02 +04:00
rcu_irq_exit ( ) ;
2013-11-19 19:42:47 +04:00
trace_hardirq_exit ( ) ; /* must be last! */
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 ) ;
2009-07-22 16:18:35 +04:00
/*
* tasklet_hrtimer
*/
/*
2010-02-03 20:08:52 +03:00
* The trampoline is called when the hrtimer expires . It schedules a tasklet
* to run __tasklet_hrtimer_trampoline ( ) which in turn will call the intended
* hrtimer callback , but from softirq context .
2009-07-22 16:18:35 +04:00
*/
static enum hrtimer_restart __hrtimer_tasklet_trampoline ( struct hrtimer * timer )
{
struct tasklet_hrtimer * ttimer =
container_of ( timer , struct tasklet_hrtimer , timer ) ;
2010-02-03 20:08:52 +03:00
tasklet_hi_schedule ( & ttimer - > tasklet ) ;
return HRTIMER_NORESTART ;
2009-07-22 16:18:35 +04:00
}
/*
* Helper function which calls the hrtimer callback from
* tasklet / softirq context
*/
static void __tasklet_hrtimer_trampoline ( unsigned long data )
{
struct tasklet_hrtimer * ttimer = ( void * ) data ;
enum hrtimer_restart restart ;
restart = ttimer - > function ( & ttimer - > timer ) ;
if ( restart ! = HRTIMER_NORESTART )
hrtimer_restart ( & ttimer - > timer ) ;
}
/**
* tasklet_hrtimer_init - Init a tasklet / hrtimer combo for softirq callbacks
* @ ttimer : tasklet_hrtimer which is initialized
2011-03-31 05:57:33 +04:00
* @ function : hrtimer callback function which gets called from softirq context
2009-07-22 16:18:35 +04:00
* @ which_clock : clock id ( CLOCK_MONOTONIC / CLOCK_REALTIME )
* @ mode : hrtimer mode ( HRTIMER_MODE_ABS / HRTIMER_MODE_REL )
*/
void tasklet_hrtimer_init ( struct tasklet_hrtimer * ttimer ,
enum hrtimer_restart ( * function ) ( struct hrtimer * ) ,
clockid_t which_clock , enum hrtimer_mode mode )
{
hrtimer_init ( & ttimer - > timer , which_clock , mode ) ;
ttimer - > timer . function = __hrtimer_tasklet_trampoline ;
tasklet_init ( & ttimer - > tasklet , __tasklet_hrtimer_trampoline ,
( unsigned long ) ttimer ) ;
ttimer - > function = function ;
}
EXPORT_SYMBOL_GPL ( tasklet_hrtimer_init ) ;
2005-04-17 02:20:36 +04:00
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 ;
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 ;
}