netdev: show a process of packets
Subsystems (4)
v3 cover netdev: show a process of packets
CHANGE-LOG since v2:
1) let all tracepoints of softirq use DECLARE_EVENT_CLASS
2) let tracepoint of netdev_queue and netdev_receive use DECLARE_EVENT_CLASS
3) add tracepoint to skb_free_datagram_locked
4) show function and time when received packet is freed
These patch-set adds tracepoints to show us a process of packets. Using these tracepoints and existing points, we can get the time when packet passes through some points in transmit or receive sequence. For example, this is an output of perf script which is attached by patch 5/5.
79074.756672832sec cpu=1irq_entry(+0.000000msec,irq=77:eth3)
|------------softirq_raise(+0.001277msec)
irq_exit (+0.002278msec) |
|
softirq_entry(+0.003562msec)
|
|---netif_receive_skb(+0.006279msec,len=100)
| |
| skb_copy_datagram_iovec(+0.038778msec, 2285:sshd)
|
napi_poll_exit(+0.017160msec, eth3)
|
softirq_exit(+0.018248msec)The above is a receive side. Like this, it can show receive sequence from interrupt(irq_entry) to application(skb_copy_datagram_iovec). There are eight points in this side. All events except for skb_copy_datagram_iovec and freeing skb events can be associated with each other by CPU number. skb_copy_datagram_iovec and freeing skb events can be associated with netif_receive_skb by skbaddr.
This script shows one NET_RX softirq and events related to it. All relative time bases on first irq_entry which raise NET_RX softirq.
dev len Qdisc netdevice free eth3 114 79044.417123332sec 0.005242msec 0.103843msec eth3 114 79044.580090422sec 0.002306msec 0.103632msec eth3 114 79044.719078251sec 0.002288msec 0.104093msec
The above is a transmit side. There are three tracepoints in this side. Point1 is before putting a packet to Qdisc. point2 is after ndo_start_xmit in dev_hard_start_xmit. It indicates finishing putting a packet to driver. point3 is in consume_skb and dev_kfree_skb_irq. It indicates freeing a transmitted packet.
Values of this script are, from left, device name, length of a packet, a time of point1, an interval time between point1 and point2 and an interval time between point2 and point3.
These times are useful to analyze a performance or to detect a point where packet delays. For example,
- NET_RX softirq calling is late.
- Application is late to take a packet.
- It takes much time to put a transmitting packet to driver (It may be caused by packed queue)
And also, these tracepoint help us to investigate a network driver's trouble from memory dump because ftrace records it to memory. And ftrace is so light even if always trace on. So, in a case investigating a problem which doesn't reproduce, it is useful.
Thanks,
Koki Sanagi.
RFC PATCH v3 1/5 irq: add tracepoint to softirq_raise
From: Lai Jiangshan <[email protected]>
Add a tracepoint for tracing when softirq action is raised.
It and the existed tracepoints complete softirq's tracepoints:softirq_raise, softirq_entry and softirq_exit.
And when this tracepoint is used in combination with the softirq_entry tracepoint we can determine the softirq raise latency.
--- include/linux/interrupt.h | 8 +++++- include/trace/events/irq.h | 57 ++++++++++++++++++++++++++----------------- kernel/softirq.c | 4 +- 3 files changed, 43 insertions(+), 26 deletions(-)
include/linux/interrupt.h +7 -1
@@ -18,6 +18,7 @@#include <asm/atomic.h> #include <asm/ptrace.h> #include <asm/system.h> +#include <trace/events/irq.h> /* * These correspond to the IORESOURCE_IRQ_* defines in
@@ -402,7 +403,12 @@ asmlinkage void do_softirq(void); asmlinkage void __do_softirq(void);extern void open_softirq (int nr,void (*action)(struct softirq_action *));extern void softirq_init (void ); -#define __raise_softirq_irqoff (nr) do { or_softirq_pending(1UL << (nr)); } while (0) +static inline void __raise_softirq_irqoff (unsigned int nr) +{ +trace_softirq_raise (nr); +or_softirq_pending (1UL << nr); +} +extern void raise_softirq_irqoff (unsigned int nr);extern void raise_softirq (unsigned int nr);extern void wakeup_softirqd (void );
include/trace/events/irq.h +34 -23
97 lines not on this page · raw message
kernel/softirq.c +2 -2
@@ -215,9 +215,9 @@ restart:int prev_count =preempt_count ();kstat_incr_softirqs_this_cpu (h - softirq_vec); -trace_softirq_entry (h, softirq_vec); +trace_softirq_entry (h - softirq_vec); h->action (h); -trace_softirq_exit (h, softirq_vec); +trace_softirq_exit (h - softirq_vec);if (unlikely (prev_count !=preempt_count ())) {printk (KERN_ERR "huh, entered softirq %td %s %p" "with preempt_count %08x,"
RFC PATCH v3 2/5 napi: convert trace_napi_poll to TRACE_EVENT
In reply to Koki SanagiFrom: Neil Horman <[email protected]>
This patch converts trace_napi_poll from DECLARE_EVENT to TRACE_EVENT to improve the usability of napi_poll tracepoint.
<idle>-0 [001] 241302.750777: napi_poll: napi poll on napi struct f6acc480 for device eth3
<idle>-0 [000] 241302.852389: napi_poll: napi poll on napi struct f5d0d70c for device eth1An original patch is below.
http://marc.info/?l=linux-kernel&m=126021713809450&w=2
And add a fix by Steven Rostedt.
http://marc.info/?l=linux-kernel&m=126150506519173&w=2
--- include/trace/events/napi.h | 25 +++++++++++++++++++++++-- 1 files changed, 23 insertions(+), 2 deletions(-)
include/trace/events/napi.h +23 -2
@@ -6,10 +6,31 @@#include <linux/netdevice.h> #include <linux/tracepoint.h> +#include <linux/ftrace.h> + +#define NO_DEV "(no_device)" + +TRACE_EVENT (napi_poll, -DECLARE_TRACE (napi_poll, TP_PROTO(struct napi_struct *napi), -TP_ARGS (napi)); + +TP_ARGS (napi), + +TP_STRUCT__entry ( + __field( struct napi_struct *, napi) +__string ( dev_name, napi->dev ? napi->dev->name :NO_DEV ) + ), + +TP_fast_assign ( + __entry->napi = napi; + __assign_str(dev_name, napi->dev ? napi->dev->name : NO_DEV); + ), + +TP_printk ("napi poll on napi struct %p for device %s" , + __entry->napi,__get_str (dev_name)) +); + +#undef NO_DEV#endif /* _TRACE_NAPI_H_ */
RFC PATCH v3 3/5 netdev: add tracepoints to netdev layer
In reply to Koki SanagiThis patch adds tracepoint to dev_queue_xmit, dev_hard_start_xmit and netif_receive_skb. These tracepoints help you to monitor network driver's input/output.
sshd-4445 [001] 241367.066046: net_dev_queue: dev=eth3 skbaddr=dd6b2538 len=114
sshd-4445 [001] 241367.066047: net_dev_xmit: dev=eth3 skbaddr=dd6b2538 len=114 rc=0
<idle>-0 [001] 241367.067472: net_dev_receive: dev=eth3 skbaddr=f5e59000 len=52--- include/trace/events/net.h | 75 ++++++++++++++++++++++++++++++++++++++++++++ net/core/dev.c | 5 +++ net/core/net-traces.c | 1 + 3 files changed, 81 insertions(+), 0 deletions(-)
include/trace/events/net.h new file +75 -0
@@ -0,0 +1,75 @@ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM net + +#if !defined(_TRACE_NET_H) || defined(TRACE_HEADER_MULTI_READ ) +#define _TRACE_NET_H + +#include <linux/skbuff.h> +#include <linux/netdevice.h> +#include <linux/ip.h> +#include <linux/tracepoint.h> + +TRACE_EVENT (net_dev_xmit, + + TP_PROTO(struct sk_buff *skb, + int rc), + +TP_ARGS (skb, rc), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + __field( unsigned int, len ) + __field( int, rc ) +__string ( name, skb->dev->name ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + __entry->len = skb->len; + __entry->rc = rc; + __assign_str(name, skb->dev->name); + ), + +TP_printk ("dev=%s skbaddr=%p len=%u rc=%d" , +__get_str (name), __entry->skbaddr, __entry->len, __entry->rc) +); + +DECLARE_EVENT_CLASS (net_dev_template, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + __field( unsigned int, len ) +__string ( name, skb->dev->name ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + __entry->len = skb->len; + __assign_str(name, skb->dev->name); + ), + +TP_printk ("dev=%s skbaddr=%p len=%u" , +__get_str (name), __entry->skbaddr, __entry->len) +) + +DEFINE_EVENT (net_dev_template, net_dev_queue, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) +); + +DEFINE_EVENT (net_dev_template, net_dev_receive, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) +); +#endif /* _TRACE_NET_H */ + +/* This part must be outside protection */ +#include <trace/define_trace.h>
net/core/dev.c +5 -0
@@ -130,6 +130,7 @@#include <linux/jhash.h> #include <linux/random.h> #include <trace/events/napi.h> +#include <trace/events/net.h> #include <linux/pci.h> #include "net-sysfs.h"
@@ -1955,6 +1956,7 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev, } rc = ops->ndo_start_xmit (skb, dev); +trace_net_dev_xmit (skb, rc);if (rc ==NETDEV_TX_OK )txq_trans_update (txq);return rc;
@@ -1975,6 +1977,7 @@ gso:skb_dst_drop (nskb); rc = ops->ndo_start_xmit (nskb, dev); +trace_net_dev_xmit (nskb, rc);if (unlikely (rc !=NETDEV_TX_OK )) {if (rc & ~NETDEV_TX_MASK ) goto out_kfree_gso_skb;
@@ -2165,6 +2168,7 @@ int dev_queue_xmit(struct sk_buff *skb)#ifdef CONFIG_NET_CLS_ACT skb->tc_verd =SET_TC_AT (skb->tc_verd,AT_EGRESS );#endif +trace_net_dev_queue (skb);if (q->enqueue) { rc =__dev_xmit_skb (skb, q, dev, txq); goto out;
@@ -2939,6 +2943,7 @@ int netif_receive_skb(struct sk_buff *skb)if (netdev_tstamp_prequeue)net_timestamp_check (skb); +trace_net_dev_receive (skb);#ifdef CONFIG_RPS {struct rps_dev_flow voidflow, *rflow = &voidflow;
net/core/net-traces.c +1 -0
@@ -26,6 +26,7 @@#define CREATE_TRACE_POINTS #include <trace/events/skb.h> +#include <trace/events/net.h> #include <trace/events/napi.h> EXPORT_TRACEPOINT_SYMBOL_GPL (kfree_skb);
RFC PATCH v3 4/5 skb: add tracepoints to freeing skb
In reply to Koki Sanagi[RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
This patch adds tracepoint to consume_skb, dev_kfree_skb_irq and skb_free_datagram_locked. Combinating with tracepoint on dev_hard_start_xmit, we can check how long it takes to free transmited packets. And using it, we can calculate how many packets driver had at that time. It is useful when a drop of transmited packet is a problem.
<idle>-0 [001] 241409.218333: consume_skb: skbaddr=dd6b2fb8
<idle>-0 [001] 241409.490555: dev_kfree_skb_irq: skbaddr=f5e29840
udp-recv-302 [001] 515031.206008: skb_free_datagram_locked: skbaddr=f5b1d900--- include/trace/events/skb.h | 42 ++++++++++++++++++++++++++++++++++++++++++ net/core/datagram.c | 1 + net/core/dev.c | 2 ++ net/core/skbuff.c | 1 + 4 files changed, 46 insertions(+), 0 deletions(-)
include/trace/events/skb.h +42 -0
@@ -35,6 +35,48 @@ TRACE_EVENT(kfree_skb, __entry->skbaddr, __entry->protocol, __entry->location) ); +DECLARE_EVENT_CLASS (free_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + ), + +TP_printk ("skbaddr=%p" , __entry->skbaddr) + +); + +DEFINE_EVENT (free_skb, consume_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + +DEFINE_EVENT (free_skb, dev_kfree_skb_irq, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + +DEFINE_EVENT (free_skb, skb_free_datagram_locked, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + TRACE_EVENT(skb_copy_datagram_iovec, TP_PROTO(const struct sk_buff *skb, int len),
net/core/datagram.c +1 -0
@@ -231,6 +231,7 @@ void skb_free_datagram_locked(struct sock *sk, struct sk_buff *skb) {bool slow; +trace_skb_free_datagram_locked (skb);if (likely (atomic_read (&skb->users) ==1 ))smp_rmb ();else if (likely (!atomic_dec_and_test (&skb->users)))
net/core/dev.c +2 -0
@@ -131,6 +131,7 @@#include <linux/random.h> #include <trace/events/napi.h> #include <trace/events/net.h> +#include <trace/events/skb.h> #include <linux/pci.h> #include "net-sysfs.h"
@@ -1581,6 +1582,7 @@ void dev_kfree_skb_irq(struct sk_buff *skb)struct softnet_data *sd;unsigned long flags; +trace_dev_kfree_skb_irq (skb);local_irq_save (flags); sd = &__get_cpu_var (softnet_data); skb->next = sd->completion_queue;
net/core/skbuff.c +1 -0
@@ -466,6 +466,7 @@ void consume_skb(struct sk_buff *skb)smp_rmb (); else if (likely(!atomic_dec_and_test(&skb->users))) return; +trace_consume_skb (skb );__kfree_skb (skb); }EXPORT_SYMBOL (consume_skb);
RFC PATCH v3 5/5 perf:add a script shows a process of packet
In reply to Koki SanagiAdd a perf script which shows a process of packets and processed time. It helps us to investigate networking or network device.
If you want to use it, install perf and record perf.data like following.
#perf trace record netdev-times [script]
If you set script, perf gathers records until it ends. If not, you must Ctrl-C to stop recording.
And if you want a report from record,
#perf trace report netdev-times [options]
If you use some options, you can limit an output.
Option is below.
tx: show only process of tx packets
rx: show only process of rx packets
dev=: show a process specified with this option
debug: work with debug mode. It shows buffer status.
For example, if you want to show a process of received packets associated with eth3,
#perf trace report netdev-times rx dev=eth3
79074.756672832sec cpu=1irq_entry(+0.000000msec,irq=77:eth3)
|------------softirq_raise(+0.001277msec)
irq_exit (+0.002278msec) |
softirq_entry(+0.003562msec
|
|---netif_receive_skb(+0.006279msec,len=100)
| |
| skb_copy_datagram_iovec(+0.038778msec, 2285:sshd)
|
napi_poll_exit(+0.017160msec, eth3)
|
softirq_exit(+0.018248msec)This perf script helps us to analyze a process time of transmit/receive sequence.
--- tools/perf/scripts/python/bin/netdev-times-record | 8 + tools/perf/scripts/python/bin/netdev-times-report | 5 + tools/perf/scripts/python/netdev-times.py | 478 +++++++++++++++++++++ 3 files changed, 491 insertions(+), 0 deletions(-)
tools/perf/scripts/python/bin/netdev-times-record new file +8 -0
@@ -0,0 +1,8 @@ +#!/bin/bash +perf record -c 1 -f -R -a -e net:net_dev_xmit -e net:net_dev_queue \ + -e net:net_dev_receive -e skb:consume_skb \ + -e skb:kfree_skb -e skb:skb_free_datagram_locked \ + -e skb:dev_kfree_skb_irq -e napi:napi_poll \ + -e irq:irq_handler_entry -e irq:irq_handler_exit \ + -e irq:softirq_entry -e irq:softirq_exit \ + -e irq:softirq_raise -e skb:skb_copy_datagram_iovec $@
tools/perf/scripts/python/bin/netdev-times-report new file +5 -0
@@ -0,0 +1,5 @@ +#!/bin/bash +# description: display a process of packet and processing time +# args: [tx] [rx] [dev=] [debug] + +perf trace -s ~/libexec/perf-core/scripts/python/netdev-times.py $@
tools/perf/scripts/python/less new file +0 -0
tools/perf/scripts/python/netdev-times.py new file +478 -0
478 lines not on this page · raw message
Re: [RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
In reply to Koki SanagiQuoted 79 lines · Koki Sanagi
[RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
This patch adds tracepoint toconsume_skb,dev_kfree_skb_irqandskb_free_datagram_locked. Combinating with tracepoint ondev_hard_start_xmit, we can check how long it takes to free transmited packets. And using it, we can calculate how many packets driver had at that time. It is useful when a drop of transmited packet is a problem.<idle>-0 [001] 241409.218333: consume_skb: skbaddr=dd6b2fb8 <idle>-0 [001] 241409.490555: dev_kfree_skb_irq: skbaddr=f5e29840 udp-recv-302 [001] 515031.206008: skb_free_datagram_locked: skbaddr=f5b1d900Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/skb.h | 42 ++++++++++++++++++++++++++++++++++++++++++ net/core/datagram.c | 1 + net/core/dev.c | 2 ++ net/core/skbuff.c | 1 + 4 files changed, 46 insertions(+), 0 deletions(-)include/trace/events/skb.h +42
-0@@ -35,6 +35,48 @@ TRACE_EVENT(kfree_skb, __entry->skbaddr, __entry->protocol, __entry->location) ); +DECLARE_EVENT_CLASS (free_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + ), + +TP_printk ("skbaddr=%p" , __entry->skbaddr) + +); + +DEFINE_EVENT (free_skb, consume_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + +DEFINE_EVENT (free_skb, dev_kfree_skb_irq, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + +DEFINE_EVENT (free_skb, skb_free_datagram_locked, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + TRACE_EVENT(skb_copy_datagram_iovec, TP_PROTO(const struct sk_buff *skb, int len),net/core/datagram.c +0
-0
net/core/datagram.c void skb_free_datagram_locked(struct sock *sk, struct sk_buff *skb) · line 234
Quoted 4 lines
net/core/datagram.c +1
-0@@ -231,6 +231,7 @@ void skb_free_datagram_locked(struct sock *sk, struct sk_buff *skb) {bool slow; +trace_skb_free_datagram_locked (skb);
Here you unconditionally trace before the test on skb->users
Quoted 28 lines
net/core/datagram.c +0
-0if (likely (atomic_read (&skb->users) ==1 ))smp_rmb ();else if (likely (!atomic_dec_and_test (&skb->users)))net/core/dev.c +2
-0@@ -131,6 +131,7 @@#include <linux/random.h> #include <trace/events/napi.h> #include <trace/events/net.h> +#include <trace/events/skb.h> #include <linux/pci.h> #include "net-sysfs.h" @@ -1581,6 +1582,7 @@ void dev_kfree_skb_irq(struct sk_buff *skb)struct softnet_data *sd;unsigned long flags; +trace_dev_kfree_skb_irq (skb);local_irq_save (flags); sd = &__get_cpu_var (softnet_data); skb->next = sd->completion_queue;net/core/skbuff.c +0
-0
net/core/skbuff.c void consume_skb(struct sk_buff *skb) · line 468
Quoted 3 lines
net/core/skbuff.c +0
-0@@ -466,6 +466,7 @@ void consume_skb(struct sk_buff *skb)smp_rmb (); else if (likely(!atomic_dec_and_test(&skb->users))) return;
While here you trace _after_ the test on skb->users - and a "return;" , so you miss some consume_skb() calls
Quoted 5 lines
net/core/skbuff.c +1
-0+trace_consume_skb (skb);__kfree_skb (skb); }EXPORT_SYMBOL (consume_skb);
Re: [RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
Quoted 106 lines · Eric Dumazet
Quoted 79 lines · Koki Sanagi
[RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
This patch adds tracepoint toconsume_skb,dev_kfree_skb_irqandskb_free_datagram_locked. Combinating with tracepoint ondev_hard_start_xmit, we can check how long it takes to free transmited packets. And using it, we can calculate how many packets driver had at that time. It is useful when a drop of transmited packet is a problem.<idle>-0 [001] 241409.218333: consume_skb: skbaddr=dd6b2fb8 <idle>-0 [001] 241409.490555: dev_kfree_skb_irq: skbaddr=f5e29840 udp-recv-302 [001] 515031.206008: skb_free_datagram_locked: skbaddr=f5b1d900Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/skb.h | 42 ++++++++++++++++++++++++++++++++++++++++++ net/core/datagram.c | 1 + net/core/dev.c | 2 ++ net/core/skbuff.c | 1 + 4 files changed, 46 insertions(+), 0 deletions(-)include/trace/events/skb.h +42
-0@@ -35,6 +35,48 @@ TRACE_EVENT(kfree_skb, __entry->skbaddr, __entry->protocol, __entry->location) ); +DECLARE_EVENT_CLASS (free_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + ), + +TP_printk ("skbaddr=%p" , __entry->skbaddr) + +); + +DEFINE_EVENT (free_skb, consume_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + +DEFINE_EVENT (free_skb, dev_kfree_skb_irq, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + +DEFINE_EVENT (free_skb, skb_free_datagram_locked, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + TRACE_EVENT(skb_copy_datagram_iovec, TP_PROTO(const struct sk_buff *skb, int len),net/core/datagram.c +0
-0net/core/datagram.c void skb_free_datagram_locked(struct sock *sk, struct sk_buff *skb) · line 234
Quoted 4 lines
net/core/datagram.c +1
-0@@ -231,6 +231,7 @@ void skb_free_datagram_locked(struct sock *sk, struct sk_buff *skb) {bool slow; +trace_skb_free_datagram_locked (skb);Here you unconditionally trace before the test on
skb->usersQuoted 19 lines
net/core/datagram.c +0
-0if (likely (atomic_read (&skb->users) ==1 ))smp_rmb ();else if (likely (!atomic_dec_and_test (&skb->users)))net/core/dev.c +1
-0@@ -131,6 +131,7 @@#include <linux/random.h> #include <trace/events/napi.h> #include <trace/events/net.h> +#include <trace/events/skb.h> #include <linux/pci.h> #include "net-sysfs.h" @@ -1581,6 +1582,7 @@ void dev_kfree_skb_irq(struct sk_buff *skb)struct softnet_data *sd;unsigned long flags;
Quoted 16 lines
net/core/skbuff.c void consume_skb(struct sk_buff *skb) · line 468
Quoted 12 lines
net/core/dev.c +1
-0+trace_dev_kfree_skb_irq (skb);local_irq_save (flags); sd = &__get_cpu_var (softnet_data); skb->next = sd->completion_queue;net/core/skbuff.c +0
-0@@ -466,6 +466,7 @@ void consume_skb(struct sk_buff *skb)smp_rmb (); else if (likely(!atomic_dec_and_test(&skb->users))) return;While here you trace _after_ the test on
skb->users- and a "return;" , so you miss someconsume_skb()calls
Yeah, I'll move trace_consume_skb() before the test.
Thanks,
Koki Sanagi.
Quoted 10 lines
Quoted 6 lines
net/core/skbuff.c +1
-0+trace_consume_skb (skb);__kfree_skb (skb); }EXPORT_SYMBOL (consume_skb);
Re: [RFC PATCH v3 1/5] irq: add tracepoint to softirq_raise
In reply to Koki SanagiQuoted 36 lines · Koki Sanagi
From: Lai Jiangshan <[email protected]>
Add a tracepoint for tracing when softirq action is raised.
It and the existed tracepoints complete softirq's tracepoints:
softirq_raise,softirq_entryandsoftirq_exit.And when this tracepoint is used in combination with the
softirq_entrytracepoint we can determine the softirq raise latency.Signed-off-by Lai Jiangshan <[email protected]>[ factorize softirq events with DECLARE_EVENT_CLASS ]Signed-off-by Koki Sanagi <[email protected]>--- include/linux/interrupt.h | 8 +++++- include/trace/events/irq.h | 57 ++++++++++++++++++++++++++----------------- kernel/softirq.c | 4 +- 3 files changed, 43 insertions(+), 26 deletions(-)include/linux/interrupt.h +1
-0@@ -18,6 +18,7 @@#include <asm/atomic.h> #include <asm/ptrace.h> #include <asm/system.h> +#include <trace/events/irq.h> /* * These correspond to the IORESOURCE_IRQ_* defines in
include/linux/interrupt.h asmlinkage void do_softirq(void); · line 411
Quoted 10 lines
include/linux/interrupt.h +6
-1@@ -402,7 +403,12 @@ asmlinkage void do_softirq(void); asmlinkage void __do_softirq(void);extern void open_softirq (int nr,void (*action)(struct softirq_action *));extern void softirq_init (void ); -#define __raise_softirq_irqoff (nr) do { or_softirq_pending(1UL << (nr)); } while (0) +static inline void __raise_softirq_irqoff (unsigned int nr) +{ +trace_softirq_raise (nr); +or_softirq_pending (1UL << nr); +} +
We already have tracepoints in irq_enter and irq_exit. If the goal here is to detect latency during packet processing, cant the delta in time between those two points be used to determine interrupt handling latency?
Quoted 111 lines
include/linux/interrupt.h +0
-0extern void raise_softirq_irqoff (unsigned int nr);extern void raise_softirq (unsigned int nr);extern void wakeup_softirqd (void );include/trace/events/irq.h +34
-23@@ -5,7 +5,9 @@#define _TRACE_IRQ_H#include <linux/tracepoint.h> -#include <linux/interrupt.h> + +struct irqaction ; +struct softirq_action ;#define softirq_name (sirq) { sirq##_SOFTIRQ, #sirq }#define show_softirq_name (val) \@@ -84,56 +86,65 @@ TRACE_EVENT(irq_handler_exit,DECLARE_EVENT_CLASS (softirq, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec), +TP_ARGS (nr),TP_STRUCT__entry ( -__field ( int, vec ) + __field( unsigned int, vec ) ),TP_fast_assign ( - __entry->vec = (int)(h - vec); + __entry->vec = nr; ),TP_printk ("vec=%d [action=%s]" , __entry->vec, -show_softirq_name (__entry->vec)) +show_softirq_name (__entry->vec)) +); + +/** +* softirq_raise - called immediately when a softirq is raised +* @nr: softirq vector number +* +* Tracepoint for tracing when softirq action is raised. +* Also, when used in combination with the softirq_entry tracepoint +* we can determine the softirq raise latency. +*/ +DEFINE_EVENT (softirq, softirq_raise, + + TP_PROTO(unsigned int nr), + +TP_ARGS (nr) );/** * softirq_entry - called immediately before the softirq handler -* @h: pointer to struct softirq_action -* @vec: pointer to first struct softirq_action in softirq_vec array +* @nr: softirq vector number * -* The @h parameter, contains a pointer to the struct softirq_action -* which has a pointer to the action handler that is called. By subtracting -* the @vec pointer from the @h pointer, we can determine the softirq -* number. Also, when used in combination with the softirq_exit tracepoint +* Tracepoint for tracing when softirq action starts. +* Also, when used in combination with the softirq_exit tracepoint * we can determine the softirq latency. */ DEFINE_EVENT (softirq, softirq_entry, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec) +TP_ARGS (nr) );/** * softirq_exit - called immediately after the softirq handler returns -* @h: pointer to struct softirq_action -* @vec: pointer to first struct softirq_action in softirq_vec array +* @nr: softirq vector number * -* The @h parameter contains a pointer to the struct softirq_action -* that has handled the softirq. By subtracting the @vec pointer from -* the @h pointer, we can determine the softirq number. Also, when used in -* combination with the softirq_entry tracepoint we can determine the softirq -* latency. +* Tracepoint for tracing when softirq action ends. +* Also, when used in combination with the softirq_entry tracepoint +* we can determine the softirq latency. */ DEFINE_EVENT (softirq, softirq_exit, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec) +TP_ARGS (nr) );#endif /* _TRACE_IRQ_H */ kernel/softirq.c +0
-0
kernel/softirq.c restart: · line 220
Quoted 8 lines
kernel/softirq.c +2
-2@@ -215,9 +215,9 @@ restart:int prev_count =preempt_count ();kstat_incr_softirqs_this_cpu (h - softirq_vec); -trace_softirq_entry (h, softirq_vec); +trace_softirq_entry (h - softirq_vec); h->action (h); -trace_softirq_exit (h, softirq_vec); +trace_softirq_exit (h - softirq_vec);
You're loosing information here by reducing the numbers of parameters in this tracepoint. How many other tracepoint scripts rely on having both pointers handy? Why not just do the pointer math inside your tracehook instead?
Quoted 9 lines
kernel/softirq.c +0
-1if (unlikely (prev_count !=preempt_count ())) {printk (KERN_ERR "huh, entered softirq %td %s %p" "with preempt_count %08x," --To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Neil Horman
NAKRe: [RFC PATCH v3 2/5] napi: convert trace_napi_poll to TRACE_EVENT
In reply to Koki SanagiQuoted 49 lines · Koki Sanagi
From: Neil Horman <[email protected]>
This patch converts
trace_napi_pollfromDECLARE_EVENTtoTRACE_EVENTto improve the usability ofnapi_polltracepoint.<idle>-0 [001] 241302.750777: napi_poll: napi poll on napi struct f6acc480 for device eth3 <idle>-0 [000] 241302.852389: napi_poll: napi poll on napi struct f5d0d70c for device eth1An original patch is below.
http://marc.info/?l=linux-kernel&m=126021713809450&w=2Signed-off-by Neil Horman <[email protected]>And add a fix by Steven Rostedt.
http://marc.info/?l=linux-kernel&m=126150506519173&w=2Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/napi.h | 25 +++++++++++++++++++++++-- 1 files changed, 23 insertions(+), 2 deletions(-)include/trace/events/napi.h +16
-2@@ -6,10 +6,31 @@#include <linux/netdevice.h> #include <linux/tracepoint.h> +#include <linux/ftrace.h> + +#define NO_DEV "(no_device)" + +TRACE_EVENT(napi_poll, -DECLARE_TRACE (napi_poll, TP_PROTO(struct napi_struct *napi), -TP_ARGS (napi)); + + TP_ARGS(napi), + + TP_STRUCT__entry( + __field( struct napi_struct *, napi) + __string( dev_name, napi->dev ? napi->dev->name : NO_DEV) + ), + + TP_fast_assign( + __entry->napi = napi; + __assign_str(dev_name, napi->dev ? napi->dev->name : NO_DEV);
include/trace/events/napi.h line 36
Quoted 10 lines
include/trace/events/napi.h +7
-0+ ), + +TP_printk ("napi poll on napi struct %p for device %s" , + __entry->napi,__get_str (dev_name)) +); + +#undef NO_DEV#endif /* _TRACE_NAPI_H_ */
NAK, This change will create a build break in the drop monitor code. You'll need to fix that up if you want to make this change.
Neil
Re: [RFC PATCH v3 3/5] netdev: add tracepoints to netdev layer
In reply to Koki SanagiQuoted 133 lines · Koki Sanagi
This patch adds tracepoint to
dev_queue_xmit,dev_hard_start_xmitandnetif_receive_skb. These tracepoints help you to monitor network driver's input/output.sshd-4445 [001] 241367.066046: net_dev_queue: dev=eth3 skbaddr=dd6b2538 len=114 sshd-4445 [001] 241367.066047: net_dev_xmit: dev=eth3 skbaddr=dd6b2538 len=114 rc=0 <idle>-0 [001] 241367.067472: net_dev_receive: dev=eth3 skbaddr=f5e59000 len=52Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/net.h | 75 ++++++++++++++++++++++++++++++++++++++++++++ net/core/dev.c | 5 +++ net/core/net-traces.c | 1 + 3 files changed, 81 insertions(+), 0 deletions(-)include/trace/events/net.h new file +75
-0@@ -0,0 +1,75 @@ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM net + +#if !defined(_TRACE_NET_H) || defined(TRACE_HEADER_MULTI_READ ) +#define _TRACE_NET_H + +#include <linux/skbuff.h> +#include <linux/netdevice.h> +#include <linux/ip.h> +#include <linux/tracepoint.h> + +TRACE_EVENT (net_dev_xmit, + + TP_PROTO(struct sk_buff *skb, + int rc), + +TP_ARGS (skb, rc), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + __field( unsigned int, len ) + __field( int, rc ) +__string ( name, skb->dev->name ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + __entry->len = skb->len; + __entry->rc = rc; + __assign_str(name, skb->dev->name); + ), + +TP_printk ("dev=%s skbaddr=%p len=%u rc=%d" , +__get_str (name), __entry->skbaddr, __entry->len, __entry->rc) +); + +DECLARE_EVENT_CLASS (net_dev_template, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + __field( unsigned int, len ) +__string ( name, skb->dev->name ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + __entry->len = skb->len; + __assign_str(name, skb->dev->name); + ), + +TP_printk ("dev=%s skbaddr=%p len=%u" , +__get_str (name), __entry->skbaddr, __entry->len) +) + +DEFINE_EVENT (net_dev_template, net_dev_queue, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) +); + +DEFINE_EVENT (net_dev_template, net_dev_receive, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) +); +#endif /* _TRACE_NET_H */ + +/* This part must be outside protection */ +#include <trace/define_trace.h> net/core/dev.c +4
-0@@ -130,6 +130,7 @@#include <linux/jhash.h> #include <linux/random.h> #include <trace/events/napi.h> +#include <trace/events/net.h> #include <linux/pci.h> #include "net-sysfs.h" @@ -1955,6 +1956,7 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev, } rc = ops->ndo_start_xmit (skb, dev); +trace_net_dev_xmit (skb, rc);if (rc ==NETDEV_TX_OK )txq_trans_update (txq);return rc;@@ -1975,6 +1977,7 @@ gso:skb_dst_drop (nskb); rc = ops->ndo_start_xmit (nskb, dev); +trace_net_dev_xmit (nskb, rc);if (unlikely (rc !=NETDEV_TX_OK )) {if (rc & ~NETDEV_TX_MASK ) goto out_kfree_gso_skb;@@ -2165,6 +2168,7 @@ int dev_queue_xmit(struct sk_buff *skb)#ifdef CONFIG_NET_CLS_ACT skb->tc_verd =SET_TC_AT (skb->tc_verd,AT_EGRESS );#endif +trace_net_dev_queue (skb);if (q->enqueue) { rc =__dev_xmit_skb (skb, q, dev, txq); goto out;
net/core/dev.c int netif_receive_skb(struct sk_buff *skb) · line 2946
Quoted 4 lines
net/core/dev.c +1
-0@@ -2939,6 +2943,7 @@ int netif_receive_skb(struct sk_buff *skb)if (netdev_tstamp_prequeue)net_timestamp_check (skb); +trace_net_dev_receive (skb);
I imagine for completeness you'll want to make a call to this in netif_rx and netif_rx_ni as well.
Re: [RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
In reply to Koki SanagiQuoted 61 lines · Koki Sanagi
[RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
This patch adds tracepoint toconsume_skb,dev_kfree_skb_irqandskb_free_datagram_locked. Combinating with tracepoint ondev_hard_start_xmit, we can check how long it takes to free transmited packets. And using it, we can calculate how many packets driver had at that time. It is useful when a drop of transmited packet is a problem.<idle>-0 [001] 241409.218333: consume_skb: skbaddr=dd6b2fb8 <idle>-0 [001] 241409.490555: dev_kfree_skb_irq: skbaddr=f5e29840 udp-recv-302 [001] 515031.206008: skb_free_datagram_locked: skbaddr=f5b1d900Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/skb.h | 42 ++++++++++++++++++++++++++++++++++++++++++ net/core/datagram.c | 1 + net/core/dev.c | 2 ++ net/core/skbuff.c | 1 + 4 files changed, 46 insertions(+), 0 deletions(-)include/trace/events/skb.h +32
-0@@ -35,6 +35,48 @@ TRACE_EVENT(kfree_skb, __entry->skbaddr, __entry->protocol, __entry->location) ); +DECLARE_EVENT_CLASS (free_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + ), + +TP_printk ("skbaddr=%p" , __entry->skbaddr) + +); + +DEFINE_EVENT (free_skb, consume_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + +DEFINE_EVENT (free_skb, dev_kfree_skb_irq, + + TP_PROTO(struct sk_buff *skb), + + TP_ARGS(skb) +
include/trace/events/skb.h TRACE_EVENT(kfree_skb, · line 79
Quoted 10 lines
include/trace/events/skb.h +10
-0+); + +DEFINE_EVENT (free_skb, skb_free_datagram_locked, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); +
Why create these last two tracepoints at all? dev_kfree_skb_irq will eventually pass through kfree_skb anyway, getting picked up by the tracepoint there, the while the latter won't (since it uses __kfree_skb instead), I think that could be fixed up by add a call to trace_kfree_skb there directly, saving you two tracepoints.
Neil
Quoted 1 line
Re: [RFC PATCH v3 1/5] irq: add tracepoint to softirq_raise
In reply to Neil HormanQuoted 34 lines · Neil Horman
Quoted 33 lines · Koki Sanagi
From: Lai Jiangshan <[email protected]>
Add a tracepoint for tracing when softirq action is raised.
It and the existed tracepoints complete softirq's tracepoints:
softirq_raise,softirq_entryandsoftirq_exit.And when this tracepoint is used in combination with the
softirq_entrytracepoint we can determine the softirq raise latency.Signed-off-by Lai Jiangshan <[email protected]>[ factorize softirq events with DECLARE_EVENT_CLASS ]Signed-off-by Koki Sanagi <[email protected]>--- include/linux/interrupt.h | 8 +++++- include/trace/events/irq.h | 57 ++++++++++++++++++++++++++----------------- kernel/softirq.c | 4 +- 3 files changed, 43 insertions(+), 26 deletions(-)include/linux/interrupt.h +1
-0@@ -18,6 +18,7 @@#include <asm/atomic.h> #include <asm/ptrace.h> #include <asm/system.h> +#include <trace/events/irq.h>
Quoted 16 lines
include/linux/interrupt.h asmlinkage void do_softirq(void); · line 411
Quoted 13 lines
include/linux/interrupt.h +6
-1/* * These correspond to the IORESOURCE_IRQ_* defines in @@ -402,7 +403,12 @@ asmlinkage void do_softirq(void); asmlinkage void __do_softirq(void);extern void open_softirq (int nr,void (*action)(struct softirq_action *));extern void softirq_init (void ); -#define __raise_softirq_irqoff (nr) do { or_softirq_pending(1UL << (nr)); } while (0) +static inline void __raise_softirq_irqoff (unsigned int nr) +{ +trace_softirq_raise (nr); +or_softirq_pending (1UL << nr); +} +We already have tracepoints in
irq_enterandirq_exit. If the goal here is to detect latency during packet processing, cant the delta in time between those two points be used to determine interrupt handling latency?
Certainly, the time between irq_entry and irq_exit is not directly related to latency during packet processing. But it's indirectly related it. Because softirq_entry isn't passed until irq exits and softirq_entry time is related to packet processing latency. So I show it as a reference.
Quoted 116 lines
Quoted 116 lines
include/linux/interrupt.h +0
-0extern void raise_softirq_irqoff (unsigned int nr);extern void raise_softirq (unsigned int nr);extern void wakeup_softirqd (void );include/trace/events/irq.h +34
-23@@ -5,7 +5,9 @@#define _TRACE_IRQ_H#include <linux/tracepoint.h> -#include <linux/interrupt.h> + +struct irqaction ; +struct softirq_action ;#define softirq_name (sirq) { sirq##_SOFTIRQ, #sirq }#define show_softirq_name (val) \@@ -84,56 +86,65 @@ TRACE_EVENT(irq_handler_exit,DECLARE_EVENT_CLASS (softirq, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec), +TP_ARGS (nr),TP_STRUCT__entry ( -__field ( int, vec ) + __field( unsigned int, vec ) ),TP_fast_assign ( - __entry->vec = (int)(h - vec); + __entry->vec = nr; ),TP_printk ("vec=%d [action=%s]" , __entry->vec, -show_softirq_name (__entry->vec)) +show_softirq_name (__entry->vec)) +); + +/** +* softirq_raise - called immediately when a softirq is raised +* @nr: softirq vector number +* +* Tracepoint for tracing when softirq action is raised. +* Also, when used in combination with the softirq_entry tracepoint +* we can determine the softirq raise latency. +*/ +DEFINE_EVENT (softirq, softirq_raise, + + TP_PROTO(unsigned int nr), + +TP_ARGS (nr) );/** * softirq_entry - called immediately before the softirq handler -* @h: pointer to struct softirq_action -* @vec: pointer to first struct softirq_action in softirq_vec array +* @nr: softirq vector number * -* The @h parameter, contains a pointer to the struct softirq_action -* which has a pointer to the action handler that is called. By subtracting -* the @vec pointer from the @h pointer, we can determine the softirq -* number. Also, when used in combination with the softirq_exit tracepoint +* Tracepoint for tracing when softirq action starts. +* Also, when used in combination with the softirq_exit tracepoint * we can determine the softirq latency. */ DEFINE_EVENT (softirq, softirq_entry, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec) +TP_ARGS (nr) );/** * softirq_exit - called immediately after the softirq handler returns -* @h: pointer to struct softirq_action -* @vec: pointer to first struct softirq_action in softirq_vec array +* @nr: softirq vector number * -* The @h parameter contains a pointer to the struct softirq_action -* that has handled the softirq. By subtracting the @vec pointer from -* the @h pointer, we can determine the softirq number. Also, when used in -* combination with the softirq_entry tracepoint we can determine the softirq -* latency. +* Tracepoint for tracing when softirq action ends. +* Also, when used in combination with the softirq_entry tracepoint +* we can determine the softirq latency. */ DEFINE_EVENT (softirq, softirq_exit, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec) +TP_ARGS (nr) );#endif /* _TRACE_IRQ_H */ kernel/softirq.c +0
-0@@ -215,9 +215,9 @@ restart:int prev_count =preempt_count ();kstat_incr_softirqs_this_cpu (h - softirq_vec);
Quoted 9 lines
kernel/softirq.c restart: · line 220
Quoted 5 lines
kernel/softirq.c +2
-2-trace_softirq_entry (h, softirq_vec); +trace_softirq_entry (h - softirq_vec); h->action (h); -trace_softirq_exit (h, softirq_vec); +trace_softirq_exit (h - softirq_vec);You're loosing information here by reducing the numbers of parameters in this tracepoint. How many other tracepoint scripts rely on having both pointers handy? Why not just do the pointer math inside your tracehook instead?
In __raise_softirq_irqoff macro there is no method to refer softirq_vec, so it can't use softirq DECLARE_EVENT_CLASS as is.
Currently, there is no script using softirq_entry or softirq_exit.
Thanks,
Koki Sanagi.
Quoted 12 lines
Quoted 10 lines
kernel/softirq.c +0
-1if (unlikely (prev_count !=preempt_count ())) {printk (KERN_ERR "huh, entered softirq %td %s %p" "with preempt_count %08x," --To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 2/5] napi: convert trace_napi_poll to TRACE_EVENT
In reply to Neil HormanQuoted 57 lines · Neil Horman
Quoted 56 lines · Koki Sanagi
From: Neil Horman <[email protected]>
This patch converts
trace_napi_pollfromDECLARE_EVENTtoTRACE_EVENTto improve the usability ofnapi_polltracepoint.<idle>-0 [001] 241302.750777: napi_poll: napi poll on napi struct f6acc480 for device eth3 <idle>-0 [000] 241302.852389: napi_poll: napi poll on napi struct f5d0d70c for device eth1An original patch is below.
http://marc.info/?l=linux-kernel&m=126021713809450&w=2Signed-off-by Neil Horman <[email protected]>And add a fix by Steven Rostedt.
http://marc.info/?l=linux-kernel&m=126150506519173&w=2Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/napi.h | 25 +++++++++++++++++++++++-- 1 files changed, 23 insertions(+), 2 deletions(-)include/trace/events/napi.h +23
-2@@ -6,10 +6,31 @@#include <linux/netdevice.h> #include <linux/tracepoint.h> +#include <linux/ftrace.h> + +#define NO_DEV "(no_device)" + +TRACE_EVENT (napi_poll, -DECLARE_TRACE (napi_poll, TP_PROTO(struct napi_struct *napi), -TP_ARGS (napi)); + +TP_ARGS (napi), + +TP_STRUCT__entry ( + __field( struct napi_struct *, napi) +__string ( dev_name, napi->dev ? napi->dev->name :NO_DEV ) + ), + +TP_fast_assign ( + __entry->napi = napi; + __assign_str(dev_name, napi->dev ? napi->dev->name : NO_DEV); + ), + +TP_printk ("napi poll on napi struct %p for device %s" , + __entry->napi,__get_str (dev_name)) +); + +#undef NO_DEV
Quoted 7 lines
include/trace/events/napi.h line 36
Quoted 3 lines
include/trace/events/napi.h +0
-0#endif /* _TRACE_NAPI_H_ */ NAK, This change will create a build break in the drop monitor code. You'll need to fix that up if you want to make this change.
Neil
I built a kernel with CONFIG_NET_DROP_MONITOR=y.
But build break did not occur.
Thanks,
Koki Sanagi.
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 3/5] netdev: add tracepoints to netdev layer
In reply to Neil HormanQuoted 137 lines · Neil Horman
Quoted 136 lines · Koki Sanagi
This patch adds tracepoint to
dev_queue_xmit,dev_hard_start_xmitandnetif_receive_skb. These tracepoints help you to monitor network driver's input/output.sshd-4445 [001] 241367.066046: net_dev_queue: dev=eth3 skbaddr=dd6b2538 len=114 sshd-4445 [001] 241367.066047: net_dev_xmit: dev=eth3 skbaddr=dd6b2538 len=114 rc=0 <idle>-0 [001] 241367.067472: net_dev_receive: dev=eth3 skbaddr=f5e59000 len=52Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/net.h | 75 ++++++++++++++++++++++++++++++++++++++++++++ net/core/dev.c | 5 +++ net/core/net-traces.c | 1 + 3 files changed, 81 insertions(+), 0 deletions(-)include/trace/events/net.h new file +75
-0@@ -0,0 +1,75 @@ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM net + +#if !defined(_TRACE_NET_H) || defined(TRACE_HEADER_MULTI_READ ) +#define _TRACE_NET_H + +#include <linux/skbuff.h> +#include <linux/netdevice.h> +#include <linux/ip.h> +#include <linux/tracepoint.h> + +TRACE_EVENT (net_dev_xmit, + + TP_PROTO(struct sk_buff *skb, + int rc), + +TP_ARGS (skb, rc), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + __field( unsigned int, len ) + __field( int, rc ) +__string ( name, skb->dev->name ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + __entry->len = skb->len; + __entry->rc = rc; + __assign_str(name, skb->dev->name); + ), + +TP_printk ("dev=%s skbaddr=%p len=%u rc=%d" , +__get_str (name), __entry->skbaddr, __entry->len, __entry->rc) +); + +DECLARE_EVENT_CLASS (net_dev_template, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + __field( unsigned int, len ) +__string ( name, skb->dev->name ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + __entry->len = skb->len; + __assign_str(name, skb->dev->name); + ), + +TP_printk ("dev=%s skbaddr=%p len=%u" , +__get_str (name), __entry->skbaddr, __entry->len) +) + +DEFINE_EVENT (net_dev_template, net_dev_queue, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) +); + +DEFINE_EVENT (net_dev_template, net_dev_receive, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) +); +#endif /* _TRACE_NET_H */ + +/* This part must be outside protection */ +#include <trace/define_trace.h> net/core/dev.c +4
-0@@ -130,6 +130,7 @@#include <linux/jhash.h> #include <linux/random.h> #include <trace/events/napi.h> +#include <trace/events/net.h> #include <linux/pci.h> #include "net-sysfs.h" @@ -1955,6 +1956,7 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev, } rc = ops->ndo_start_xmit (skb, dev); +trace_net_dev_xmit (skb, rc);if (rc ==NETDEV_TX_OK )txq_trans_update (txq);return rc;@@ -1975,6 +1977,7 @@ gso:skb_dst_drop (nskb); rc = ops->ndo_start_xmit (nskb, dev); +trace_net_dev_xmit (nskb, rc);if (unlikely (rc !=NETDEV_TX_OK )) {if (rc & ~NETDEV_TX_MASK ) goto out_kfree_gso_skb;@@ -2165,6 +2168,7 @@ int dev_queue_xmit(struct sk_buff *skb)#ifdef CONFIG_NET_CLS_ACT skb->tc_verd =SET_TC_AT (skb->tc_verd,AT_EGRESS );#endif +trace_net_dev_queue (skb);if (q->enqueue) { rc =__dev_xmit_skb (skb, q, dev, txq); goto out;@@ -2939,6 +2943,7 @@ int netif_receive_skb(struct sk_buff *skb)if (netdev_tstamp_prequeue)net_timestamp_check (skb);
Quoted 5 lines
net/core/dev.c int netif_receive_skb(struct sk_buff *skb) · line 2946
Quoted 1 line
net/core/dev.c +1
-0+trace_net_dev_receive (skb);I imagine for completeness you'll want to make a call to this in
netif_rxandnetif_rx_nias well.
It might be better to add tracepoint to netif_rx to determine a time between netif_rx and netif_receive_skb.
Thanks,
Koki Sanagi.
Quoted 3 lines
Re: [RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
In reply to Neil HormanQuoted 79 lines · Neil Horman
Quoted 61 lines · Koki Sanagi
[RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
This patch adds tracepoint toconsume_skb,dev_kfree_skb_irqandskb_free_datagram_locked. Combinating with tracepoint ondev_hard_start_xmit, we can check how long it takes to free transmited packets. And using it, we can calculate how many packets driver had at that time. It is useful when a drop of transmited packet is a problem.<idle>-0 [001] 241409.218333: consume_skb: skbaddr=dd6b2fb8 <idle>-0 [001] 241409.490555: dev_kfree_skb_irq: skbaddr=f5e29840 udp-recv-302 [001] 515031.206008: skb_free_datagram_locked: skbaddr=f5b1d900Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/skb.h | 42 ++++++++++++++++++++++++++++++++++++++++++ net/core/datagram.c | 1 + net/core/dev.c | 2 ++ net/core/skbuff.c | 1 + 4 files changed, 46 insertions(+), 0 deletions(-)include/trace/events/skb.h +32
-0@@ -35,6 +35,48 @@ TRACE_EVENT(kfree_skb, __entry->skbaddr, __entry->protocol, __entry->location) ); +DECLARE_EVENT_CLASS (free_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + ), + +TP_printk ("skbaddr=%p" , __entry->skbaddr) + +); + +DEFINE_EVENT (free_skb, consume_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + +DEFINE_EVENT (free_skb, dev_kfree_skb_irq, + + TP_PROTO(struct sk_buff *skb), + + TP_ARGS(skb) +include/trace/events/skb.h TRACE_EVENT(kfree_skb, · line 79
Quoted 10 lines
include/trace/events/skb.h +10
-0+); + +DEFINE_EVENT (free_skb, skb_free_datagram_locked, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); +Why create these last two tracepoints at all?
dev_kfree_skb_irqwill eventually pass throughkfree_skbanyway, getting picked up by the tracepoint there, the while the latter won't (since it uses__kfree_skbinstead), I think that could be fixed up by add a call totrace_kfree_skbthere directly, saving you two tracepoints.
Quoted 2 lines
Neil
I think dev_kfree_skb_irq isn't chased by trace_kfree_skb or trace_consume_skb completely. Because net_tx_action frees skb by __kfree_skb. So it is better to add trace_kfree_skb before it. skb_free_datagram_locked is same.
Thanks,
Koki Sanagi.
Quoted 3 lines
Quoted 1 line
Re: [RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
Quoted 80 lines · Koki Sanagi
Quoted 79 lines · Neil Horman
Quoted 61 lines · Koki Sanagi
[RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
This patch adds tracepoint toconsume_skb,dev_kfree_skb_irqandskb_free_datagram_locked. Combinating with tracepoint ondev_hard_start_xmit, we can check how long it takes to free transmited packets. And using it, we can calculate how many packets driver had at that time. It is useful when a drop of transmited packet is a problem.<idle>-0 [001] 241409.218333: consume_skb: skbaddr=dd6b2fb8 <idle>-0 [001] 241409.490555: dev_kfree_skb_irq: skbaddr=f5e29840 udp-recv-302 [001] 515031.206008: skb_free_datagram_locked: skbaddr=f5b1d900Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/skb.h | 42 ++++++++++++++++++++++++++++++++++++++++++ net/core/datagram.c | 1 + net/core/dev.c | 2 ++ net/core/skbuff.c | 1 + 4 files changed, 46 insertions(+), 0 deletions(-)include/trace/events/skb.h +32
-0@@ -35,6 +35,48 @@ TRACE_EVENT(kfree_skb, __entry->skbaddr, __entry->protocol, __entry->location) ); +DECLARE_EVENT_CLASS (free_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + ), + +TP_printk ("skbaddr=%p" , __entry->skbaddr) + +); + +DEFINE_EVENT (free_skb, consume_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + +DEFINE_EVENT (free_skb, dev_kfree_skb_irq, + + TP_PROTO(struct sk_buff *skb), + + TP_ARGS(skb) +include/trace/events/skb.h TRACE_EVENT(kfree_skb, · line 79
Quoted 10 lines
include/trace/events/skb.h +10
-0+); + +DEFINE_EVENT (free_skb, skb_free_datagram_locked, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); +Why create these last two tracepoints at all?
dev_kfree_skb_irqwill eventually pass throughkfree_skbanyway, getting picked up by the tracepoint there, the while the latter won't (since it uses__kfree_skbinstead), I think that could be fixed up by add a call totrace_kfree_skbthere directly, saving you two tracepoints.
Quoted 6 lines
Quoted 2 lines
Neil
I think
dev_kfree_skb_irqisn't chased bytrace_kfree_skbortrace_consume_skbcompletely. Becausenet_tx_actionfrees skb by__kfree_skb. So it is better to addtrace_kfree_skbbefore it.skb_free_datagram_lockedis same.
It isn't, you're right, but that was the point I made above. Those missed areas could be easily handled by adding calls to trace_kfree_skb which already exists, to the missed areas. Then you don't need to create those new tracepoints. The way your doing this, if someone wants to trace all skb frees in debugfs, they would have to enable three tracepoints, not just one. Not that thats the point of your patch, but its something to consider, and it simplifies your code. Neil
Quoted 8 lines
Thanks,
Koki Sanagi.Quoted 3 lines
Quoted 1 line
Re: [RFC PATCH v3 1/5] irq: add tracepoint to softirq_raise
In reply to Koki SanagiQuoted 52 lines · Koki Sanagi
Quoted 34 lines · Neil Horman
Quoted 33 lines · Koki Sanagi
From: Lai Jiangshan <[email protected]>
Add a tracepoint for tracing when softirq action is raised.
It and the existed tracepoints complete softirq's tracepoints:
softirq_raise,softirq_entryandsoftirq_exit.And when this tracepoint is used in combination with the
softirq_entrytracepoint we can determine the softirq raise latency.Signed-off-by Lai Jiangshan <[email protected]>[ factorize softirq events with DECLARE_EVENT_CLASS ]Signed-off-by Koki Sanagi <[email protected]>--- include/linux/interrupt.h | 8 +++++- include/trace/events/irq.h | 57 ++++++++++++++++++++++++++----------------- kernel/softirq.c | 4 +- 3 files changed, 43 insertions(+), 26 deletions(-)include/linux/interrupt.h +1
-0@@ -18,6 +18,7 @@#include <asm/atomic.h> #include <asm/ptrace.h> #include <asm/system.h> +#include <trace/events/irq.h> Quoted 16 lines
include/linux/interrupt.h asmlinkage void do_softirq(void); · line 411
Quoted 13 lines
include/linux/interrupt.h +6
-1/* * These correspond to the IORESOURCE_IRQ_* defines in @@ -402,7 +403,12 @@ asmlinkage void do_softirq(void); asmlinkage void __do_softirq(void);extern void open_softirq (int nr,void (*action)(struct softirq_action *));extern void softirq_init (void ); -#define __raise_softirq_irqoff (nr) do { or_softirq_pending(1UL << (nr)); } while (0) +static inline void __raise_softirq_irqoff (unsigned int nr) +{ +trace_softirq_raise (nr); +or_softirq_pending (1UL << nr); +} +We already have tracepoints in
irq_enterandirq_exit. If the goal here is to detect latency during packet processing, cant the delta in time between those two points be used to determine interrupt handling latency?
Quoted 5 lines
Certainly, the time between
irq_entryandirq_exitis not directly related to latency during packet processing. But it's indirectly related it. Becausesoftirq_entryisn't passed until irq exits andsoftirq_entrytime is related to packet processing latency. So I show it as a reference.
Its not directly related no, but look at it, the amount of processing between irq_exit and softirq_entry is minimal. The information you are trying to extract by computing the delta from irq_entry to softirq_entry is almost exactly the same as that from irq_entry to irq_exit. For that matter, since you're trying to guage lantency for packet processing, I expect you could get the same delta by measuring irq_entry to napi_poll tracepoint time, and save the hassle of needing to filter on softirq processing that doesn't relate to packet processing.
Quoted 126 lines
Quoted 116 lines
Quoted 116 lines
include/linux/interrupt.h +0
-0extern void raise_softirq_irqoff (unsigned int nr);extern void raise_softirq (unsigned int nr);extern void wakeup_softirqd (void );include/trace/events/irq.h +34
-23@@ -5,7 +5,9 @@#define _TRACE_IRQ_H#include <linux/tracepoint.h> -#include <linux/interrupt.h> + +struct irqaction ; +struct softirq_action ;#define softirq_name (sirq) { sirq##_SOFTIRQ, #sirq }#define show_softirq_name (val) \@@ -84,56 +86,65 @@ TRACE_EVENT(irq_handler_exit,DECLARE_EVENT_CLASS (softirq, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec), +TP_ARGS (nr),TP_STRUCT__entry ( -__field ( int, vec ) + __field( unsigned int, vec ) ),TP_fast_assign ( - __entry->vec = (int)(h - vec); + __entry->vec = nr; ),TP_printk ("vec=%d [action=%s]" , __entry->vec, -show_softirq_name (__entry->vec)) +show_softirq_name (__entry->vec)) +); + +/** +* softirq_raise - called immediately when a softirq is raised +* @nr: softirq vector number +* +* Tracepoint for tracing when softirq action is raised. +* Also, when used in combination with the softirq_entry tracepoint +* we can determine the softirq raise latency. +*/ +DEFINE_EVENT (softirq, softirq_raise, + + TP_PROTO(unsigned int nr), + +TP_ARGS (nr) );/** * softirq_entry - called immediately before the softirq handler -* @h: pointer to struct softirq_action -* @vec: pointer to first struct softirq_action in softirq_vec array +* @nr: softirq vector number * -* The @h parameter, contains a pointer to the struct softirq_action -* which has a pointer to the action handler that is called. By subtracting -* the @vec pointer from the @h pointer, we can determine the softirq -* number. Also, when used in combination with the softirq_exit tracepoint +* Tracepoint for tracing when softirq action starts. +* Also, when used in combination with the softirq_exit tracepoint * we can determine the softirq latency. */ DEFINE_EVENT (softirq, softirq_entry, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec) +TP_ARGS (nr) );/** * softirq_exit - called immediately after the softirq handler returns -* @h: pointer to struct softirq_action -* @vec: pointer to first struct softirq_action in softirq_vec array +* @nr: softirq vector number * -* The @h parameter contains a pointer to the struct softirq_action -* that has handled the softirq. By subtracting the @vec pointer from -* the @h pointer, we can determine the softirq number. Also, when used in -* combination with the softirq_entry tracepoint we can determine the softirq -* latency. +* Tracepoint for tracing when softirq action ends. +* Also, when used in combination with the softirq_entry tracepoint +* we can determine the softirq latency. */ DEFINE_EVENT (softirq, softirq_exit, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec) +TP_ARGS (nr) );#endif /* _TRACE_IRQ_H */ kernel/softirq.c +0
-0@@ -215,9 +215,9 @@ restart:int prev_count =preempt_count ();kstat_incr_softirqs_this_cpu (h - softirq_vec);Quoted 9 lines
kernel/softirq.c restart: · line 220
Quoted 5 lines
kernel/softirq.c +2
-2-trace_softirq_entry (h, softirq_vec); +trace_softirq_entry (h - softirq_vec); h->action (h); -trace_softirq_exit (h, softirq_vec); +trace_softirq_exit (h - softirq_vec);You're loosing information here by reducing the numbers of parameters in this tracepoint. How many other tracepoint scripts rely on having both pointers handy? Why not just do the pointer math inside your tracehook instead?
Quoted 4 lines
In
__raise_softirq_irqoffmacro there is no method to refersoftirq_vec, so it can't use softirqDECLARE_EVENT_CLASSas is.
Currently, there is no script usingsoftirq_entryorsoftirq_exit.
That shouldn't matter, just pass in NULL for softirq_vec in __raise_softirq_irqoff as the second argument to the trace function. You may need to fix up the class definition so that the assignment or printk doesn't try to dereference that pointer when its NULL, but thats easy enough, and it avoids breaking any other perf scripts floating out there.
Neil
Quoted 18 lines
Thanks,
Koki Sanagi.Quoted 12 lines
Quoted 10 lines
kernel/softirq.c +0
-1if (unlikely (prev_count !=preempt_count ())) {printk (KERN_ERR "huh, entered softirq %td %s %p" "with preempt_count %08x," --To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 2/5] napi: convert trace_napi_poll to TRACE_EVENT
In reply to Koki SanagiQuoted 65 lines · Koki Sanagi
Quoted 57 lines · Neil Horman
Quoted 56 lines · Koki Sanagi
From: Neil Horman <[email protected]>
This patch converts
trace_napi_pollfromDECLARE_EVENTtoTRACE_EVENTto improve the usability ofnapi_polltracepoint.<idle>-0 [001] 241302.750777: napi_poll: napi poll on napi struct f6acc480 for device eth3 <idle>-0 [000] 241302.852389: napi_poll: napi poll on napi struct f5d0d70c for device eth1An original patch is below.
http://marc.info/?l=linux-kernel&m=126021713809450&w=2Signed-off-by Neil Horman <[email protected]>And add a fix by Steven Rostedt.
http://marc.info/?l=linux-kernel&m=126150506519173&w=2Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/napi.h | 25 +++++++++++++++++++++++-- 1 files changed, 23 insertions(+), 2 deletions(-)include/trace/events/napi.h +23
-2@@ -6,10 +6,31 @@#include <linux/netdevice.h> #include <linux/tracepoint.h> +#include <linux/ftrace.h> + +#define NO_DEV "(no_device)" + +TRACE_EVENT (napi_poll, -DECLARE_TRACE (napi_poll, TP_PROTO(struct napi_struct *napi), -TP_ARGS (napi)); + +TP_ARGS (napi), + +TP_STRUCT__entry ( + __field( struct napi_struct *, napi) +__string ( dev_name, napi->dev ? napi->dev->name :NO_DEV ) + ), + +TP_fast_assign ( + __entry->napi = napi; + __assign_str(dev_name, napi->dev ? napi->dev->name : NO_DEV); + ), + +TP_printk ("napi poll on napi struct %p for device %s" , + __entry->napi,__get_str (dev_name)) +); + +#undef NO_DEVQuoted 7 lines
include/trace/events/napi.h line 36
Quoted 3 lines
include/trace/events/napi.h +0
-0#endif /* _TRACE_NAPI_H_ */ NAK, This change will create a build break in the drop monitor code. You'll need to fix that up if you want to make this change.
Neil
Quoted 3 lines
I built a kernel with
CONFIG_NET_DROP_MONITOR=y.
But build break did not occur.
My fault, sorry. I misunderstood what the macro change was doing here. It should be fine.
Thanks
Neil
Quoted 12 lines
Thanks,
Koki Sanagi.Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 1/5] irq: add tracepoint to softirq_raise
In reply to Neil HormanQuoted 23 lines
Quoted 19 lines
Quoted 9 lines
Quoted 9 lines
#endif /*
_TRACE_IRQ_H*/kernel/softirq.c +0
-0@@ -215,9 +215,9 @@ restart:int prev_count =preempt_count ();kstat_incr_softirqs_this_cpu (h - softirq_vec);Quoted 9 lines
kernel/softirq.c restart: · line 220
Quoted 5 lines
kernel/softirq.c +2
-2-trace_softirq_entry (h, softirq_vec); +trace_softirq_entry (h - softirq_vec); h->action (h); -trace_softirq_exit (h, softirq_vec); +trace_softirq_exit (h - softirq_vec);You're loosing information here by reducing the numbers of parameters in this tracepoint. How many other tracepoint scripts rely on having both pointers handy? Why not just do the pointer math inside your tracehook instead?
Quoted 4 lines
In
__raise_softirq_irqoffmacro there is no method to refersoftirq_vec, so it can't use softirqDECLARE_EVENT_CLASSas is.
Currently, there is no script usingsoftirq_entryorsoftirq_exit.
Quoted 5 lines
That shouldn't matter, just pass in NULL for
softirq_vecin__raise_softirq_irqoffas the second argument to the trace function. You may need to fix up the class definition so that the assignment or printk doesn't try to dereference that pointer when its NULL, but thats easy enough, and it avoids breaking any other perf scripts floating out there.
please see 5 lines above. we already have 'h - softirq_vec' calculation in this function. so, Sanagi-san's change don't makes any overhead.
So, if the overhead is zero, I'd prefer simplest tracepoint definition :)
Re: [RFC PATCH v3 1/5] irq: add tracepoint to softirq_raise
Quoted 29 lines · KOSAKI Motohiro
Quoted 23 lines
Quoted 19 lines
Quoted 9 lines
Quoted 9 lines
#endif /*
_TRACE_IRQ_H*/kernel/softirq.c +0
-0@@ -215,9 +215,9 @@ restart:int prev_count =preempt_count ();kstat_incr_softirqs_this_cpu (h - softirq_vec);Quoted 9 lines
kernel/softirq.c restart: · line 220
Quoted 5 lines
kernel/softirq.c +2
-2-trace_softirq_entry (h, softirq_vec); +trace_softirq_entry (h - softirq_vec); h->action (h); -trace_softirq_exit (h, softirq_vec); +trace_softirq_exit (h - softirq_vec);You're loosing information here by reducing the numbers of parameters in this tracepoint. How many other tracepoint scripts rely on having both pointers handy? Why not just do the pointer math inside your tracehook instead?
Quoted 4 lines
In
__raise_softirq_irqoffmacro there is no method to refersoftirq_vec, so it can't use softirqDECLARE_EVENT_CLASSas is.
Currently, there is no script usingsoftirq_entryorsoftirq_exit.Quoted 5 lines
That shouldn't matter, just pass in NULL for
softirq_vecin__raise_softirq_irqoffas the second argument to the trace function. You may need to fix up the class definition so that the assignment or printk doesn't try to dereference that pointer when its NULL, but thats easy enough, and it avoids breaking any other perf scripts floating out there.
Quoted 5 lines
please see 5 lines above. we already have 'h -
softirq_vec' calculation in this function. so, Sanagi-san's change don't makes any overhead.So, if the overhead is zero, I'd prefer simplest tracepoint definition :)
I never complained about performance here, I complained about information loss. You have a tracepoint that provides two arguments here, and you're eliminating one of them. That will potentially break other users of this tracepoint. I understand we don't normally care about that with tracepoints as much, but if we can avoid it, why don't we?
Neil
Quoted 7 lines
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
In reply to Neil HormanQuoted 87 lines · Neil Horman
Quoted 80 lines · Koki Sanagi
Quoted 79 lines · Neil Horman
Quoted 61 lines · Koki Sanagi
[RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
This patch adds tracepoint toconsume_skb,dev_kfree_skb_irqandskb_free_datagram_locked. Combinating with tracepoint ondev_hard_start_xmit, we can check how long it takes to free transmited packets. And using it, we can calculate how many packets driver had at that time. It is useful when a drop of transmited packet is a problem.<idle>-0 [001] 241409.218333: consume_skb: skbaddr=dd6b2fb8 <idle>-0 [001] 241409.490555: dev_kfree_skb_irq: skbaddr=f5e29840 udp-recv-302 [001] 515031.206008: skb_free_datagram_locked: skbaddr=f5b1d900Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/skb.h | 42 ++++++++++++++++++++++++++++++++++++++++++ net/core/datagram.c | 1 + net/core/dev.c | 2 ++ net/core/skbuff.c | 1 + 4 files changed, 46 insertions(+), 0 deletions(-)include/trace/events/skb.h +32
-0@@ -35,6 +35,48 @@ TRACE_EVENT(kfree_skb, __entry->skbaddr, __entry->protocol, __entry->location) ); +DECLARE_EVENT_CLASS (free_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + ), + +TP_printk ("skbaddr=%p" , __entry->skbaddr) + +); + +DEFINE_EVENT (free_skb, consume_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + +DEFINE_EVENT (free_skb, dev_kfree_skb_irq, + + TP_PROTO(struct sk_buff *skb), + + TP_ARGS(skb) +include/trace/events/skb.h TRACE_EVENT(kfree_skb, · line 79
Quoted 10 lines
include/trace/events/skb.h +10
-0+); + +DEFINE_EVENT (free_skb, skb_free_datagram_locked, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); +Why create these last two tracepoints at all?
dev_kfree_skb_irqwill eventually pass throughkfree_skbanyway, getting picked up by the tracepoint there, the while the latter won't (since it uses__kfree_skbinstead), I think that could be fixed up by add a call totrace_kfree_skbthere directly, saving you two tracepoints.Quoted 6 lines
Quoted 2 lines
Neil
I think
dev_kfree_skb_irqisn't chased bytrace_kfree_skbortrace_consume_skbcompletely. Becausenet_tx_actionfrees skb by__kfree_skb. So it is better to addtrace_kfree_skbbefore it.skb_free_datagram_lockedis same.
Quoted 8 lines
It isn't, you're right, but that was the point I made above. Those missed areas could be easily handled by adding calls to
trace_kfree_skbwhich already exists, to the missed areas. Then you don't need to create those new tracepoints. The way your doing this, if someone wants to trace all skb frees in debugfs, they would have to enable three tracepoints, not just one. Not that thats the point of your patch, but its something to consider, and it simplifies your code. Neil
O.K. I've re-made a patch to use trace_kfree_skb instead of trace_dev_kfree_skb_irq and trace_skb_free_datagram_locked.
But I've got a problem.
I should use not __builtin_return_address, but macro or function which returns current address. But I don't know any macro like that. Do you know any solution ?
Koki Sanagi.
--- include/trace/events/skb.h | 17 +++++++++++++++++ net/core/datagram.c | 1 + net/core/dev.c | 2 ++ net/core/skbuff.c | 1 + 4 files changed, 21 insertions(+), 0 deletions(-)
include/trace/events/skb.h +17 -0
@@ -35,6 +35,23 @@ TRACE_EVENT(kfree_skb, __entry->skbaddr, __entry->protocol, __entry->location) ); +TRACE_EVENT (consume_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + ), + +TP_printk ("skbaddr=%p" , __entry->skbaddr) +); + TRACE_EVENT(skb_copy_datagram_iovec, TP_PROTO(const struct sk_buff *skb, int len),
net/core/datagram.c +1 -0
@@ -243,6 +243,7 @@ void skb_free_datagram_locked(struct sock *sk, struct sk_buff *skb)unlock_sock_fast (sk, slow);/* skb is now orphaned, can be freed outside of locked section */ +trace_kfree_skb (skb,__builtin_return_address (0 ));__kfree_skb (skb); }EXPORT_SYMBOL (skb_free_datagram_locked);
net/core/dev.c +2 -0
@@ -131,6 +131,7 @@#include <linux/random.h> #include <trace/events/napi.h> #include <trace/events/net.h> +#include <trace/events/skb.h> #include <linux/pci.h> #include "net-sysfs.h"
@@ -2577,6 +2578,7 @@ static void net_tx_action(struct softirq_action *h) clist = clist->next;WARN_ON (atomic_read (&skb->users)); +trace_kfree_skb (skb,__builtin_return_address (0 ));__kfree_skb (skb); } }
net/core/skbuff.c +1 -0
@@ -466,6 +466,7 @@ void consume_skb(struct sk_buff *skb)smp_rmb (); else if (likely(!atomic_dec_and_test(&skb->users))) return; +trace_consume_skb (skb );__kfree_skb (skb); }EXPORT_SYMBOL (consume_skb);
Re: [RFC PATCH v3 1/5] irq: add tracepoint to softirq_raise
In reply to Neil HormanQuoted 58 lines · Neil Horman
Quoted 52 lines · Koki Sanagi
Quoted 34 lines · Neil Horman
Quoted 33 lines · Koki Sanagi
From: Lai Jiangshan <[email protected]>
Add a tracepoint for tracing when softirq action is raised.
It and the existed tracepoints complete softirq's tracepoints:
softirq_raise,softirq_entryandsoftirq_exit.And when this tracepoint is used in combination with the
softirq_entrytracepoint we can determine the softirq raise latency.Signed-off-by Lai Jiangshan <[email protected]>[ factorize softirq events with DECLARE_EVENT_CLASS ]Signed-off-by Koki Sanagi <[email protected]>--- include/linux/interrupt.h | 8 +++++- include/trace/events/irq.h | 57 ++++++++++++++++++++++++++----------------- kernel/softirq.c | 4 +- 3 files changed, 43 insertions(+), 26 deletions(-)include/linux/interrupt.h +1
-0@@ -18,6 +18,7 @@#include <asm/atomic.h> #include <asm/ptrace.h> #include <asm/system.h> +#include <trace/events/irq.h> Quoted 16 lines
include/linux/interrupt.h asmlinkage void do_softirq(void); · line 411
Quoted 13 lines
include/linux/interrupt.h +6
-1/* * These correspond to the IORESOURCE_IRQ_* defines in @@ -402,7 +403,12 @@ asmlinkage void do_softirq(void); asmlinkage void __do_softirq(void);extern void open_softirq (int nr,void (*action)(struct softirq_action *));extern void softirq_init (void ); -#define __raise_softirq_irqoff (nr) do { or_softirq_pending(1UL << (nr)); } while (0) +static inline void __raise_softirq_irqoff (unsigned int nr) +{ +trace_softirq_raise (nr); +or_softirq_pending (1UL << nr); +} +We already have tracepoints in
irq_enterandirq_exit. If the goal here is to detect latency during packet processing, cant the delta in time between those two points be used to determine interrupt handling latency?Quoted 5 lines
Certainly, the time between
irq_entryandirq_exitis not directly related to latency during packet processing. But it's indirectly related it. Becausesoftirq_entryisn't passed until irq exits andsoftirq_entrytime is related to packet processing latency. So I show it as a reference.
Quoted 8 lines
Its not directly related no, but look at it, the amount of processing between
irq_exitandsoftirq_entryis minimal. The information you are trying to extract by computing the delta fromirq_entrytosoftirq_entryis almost exactly the same as that fromirq_entrytoirq_exit. For that matter, since you're trying to guage lantency for packet processing, I expect you could get the same delta by measuringirq_entrytonapi_polltracepoint time, and save the hassle of needing to filter on softirq processing that doesn't relate to packet processing.
Yeah, to determine interrput latency, we need either one irq_exit or softirq_entry, not both.
And I think softirq_entry should be left because there is a possibility that softirq isn't triggered immidiately after irq_exit.softirq_exit isn't needed because it is not related to packet processing. softirq_raise is needed because it connects irq_entry and softirq_entry but there is no need to show it. Currently, my idea is like the following.
irq_entry(+0.000000msec,irq=77:eth3)
|
softirq_entry(+0.003562msec)
|
|---netif_receive_skb(+0.006279msec,len=100)
| |
| skb_copy_datagram_iovec(+0.038778msec, 2285:sshd)
|napi_poll_exit(+0.017160msec, eth3)
Quoted 158 lines
Quoted 127 lines
Quoted 117 lines
Quoted 117 lines
include/linux/interrupt.h +0
-0extern void raise_softirq_irqoff (unsigned int nr);extern void raise_softirq (unsigned int nr);extern void wakeup_softirqd (void );include/trace/events/irq.h +34
-23@@ -5,7 +5,9 @@#define _TRACE_IRQ_H#include <linux/tracepoint.h> -#include <linux/interrupt.h> + +struct irqaction ; +struct softirq_action ;#define softirq_name (sirq) { sirq##_SOFTIRQ, #sirq }#define show_softirq_name (val) \@@ -84,56 +86,65 @@ TRACE_EVENT(irq_handler_exit,DECLARE_EVENT_CLASS (softirq, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec), +TP_ARGS (nr),TP_STRUCT__entry ( -__field ( int, vec ) + __field( unsigned int, vec ) ),TP_fast_assign ( - __entry->vec = (int)(h - vec); + __entry->vec = nr; ),TP_printk ("vec=%d [action=%s]" , __entry->vec, -show_softirq_name (__entry->vec)) +show_softirq_name (__entry->vec)) +); + +/** +* softirq_raise - called immediately when a softirq is raised +* @nr: softirq vector number +* +* Tracepoint for tracing when softirq action is raised. +* Also, when used in combination with the softirq_entry tracepoint +* we can determine the softirq raise latency. +*/ +DEFINE_EVENT (softirq, softirq_raise, + + TP_PROTO(unsigned int nr), + +TP_ARGS (nr) );/** * softirq_entry - called immediately before the softirq handler -* @h: pointer to struct softirq_action -* @vec: pointer to first struct softirq_action in softirq_vec array +* @nr: softirq vector number * -* The @h parameter, contains a pointer to the struct softirq_action -* which has a pointer to the action handler that is called. By subtracting -* the @vec pointer from the @h pointer, we can determine the softirq -* number. Also, when used in combination with the softirq_exit tracepoint +* Tracepoint for tracing when softirq action starts. +* Also, when used in combination with the softirq_exit tracepoint * we can determine the softirq latency. */ DEFINE_EVENT (softirq, softirq_entry, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec) +TP_ARGS (nr) );/** * softirq_exit - called immediately after the softirq handler returns -* @h: pointer to struct softirq_action -* @vec: pointer to first struct softirq_action in softirq_vec array +* @nr: softirq vector number * -* The @h parameter contains a pointer to the struct softirq_action -* that has handled the softirq. By subtracting the @vec pointer from -* the @h pointer, we can determine the softirq number. Also, when used in -* combination with the softirq_entry tracepoint we can determine the softirq -* latency. +* Tracepoint for tracing when softirq action ends. +* Also, when used in combination with the softirq_entry tracepoint +* we can determine the softirq latency. */ DEFINE_EVENT (softirq, softirq_exit, - TP_PROTO(struct softirq_action *h, struct softirq_action *vec), + TP_PROTO(unsigned int nr), -TP_ARGS (h, vec) +TP_ARGS (nr) );#endif /* _TRACE_IRQ_H */ kernel/softirq.c +0
-0@@ -215,9 +215,9 @@ restart:int prev_count =preempt_count ();kstat_incr_softirqs_this_cpu (h - softirq_vec);Quoted 9 lines
kernel/softirq.c restart: · line 220
Quoted 5 lines
kernel/softirq.c +2
-2-trace_softirq_entry (h, softirq_vec); +trace_softirq_entry (h - softirq_vec); h->action (h); -trace_softirq_exit (h, softirq_vec); +trace_softirq_exit (h - softirq_vec);You're loosing information here by reducing the numbers of parameters in this tracepoint. How many other tracepoint scripts rely on having both pointers handy? Why not just do the pointer math inside your tracehook instead?
Quoted 4 lines
In
__raise_softirq_irqoffmacro there is no method to refersoftirq_vec, so it can't use softirqDECLARE_EVENT_CLASSas is.
Currently, there is no script usingsoftirq_entryorsoftirq_exit.That shouldn't matter, just pass in NULL for
softirq_vecin__raise_softirq_irqoffas the second argument to the trace function. You may need to fix up the class definition so that the assignment or printk doesn't try to dereference that pointer when its NULL, but thats easy enough, and it avoids breaking any other perf scripts floating out there.
NeilQuoted 18 lines
Thanks,
Koki Sanagi.Quoted 12 lines
Quoted 10 lines
kernel/softirq.c +0
-1if (unlikely (prev_count !=preempt_count ())) {printk (KERN_ERR "huh, entered softirq %td %s %p" "with preempt_count %08x," --To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
In reply to Koki SanagiQuoted 97 lines · Koki Sanagi
Quoted 87 lines · Neil Horman
Quoted 80 lines · Koki Sanagi
Quoted 79 lines · Neil Horman
Quoted 61 lines · Koki Sanagi
[RFC PATCH v3 4/5] skb: add tracepoints to freeing skb
This patch adds tracepoint toconsume_skb,dev_kfree_skb_irqandskb_free_datagram_locked. Combinating with tracepoint ondev_hard_start_xmit, we can check how long it takes to free transmited packets. And using it, we can calculate how many packets driver had at that time. It is useful when a drop of transmited packet is a problem.<idle>-0 [001] 241409.218333: consume_skb: skbaddr=dd6b2fb8 <idle>-0 [001] 241409.490555: dev_kfree_skb_irq: skbaddr=f5e29840 udp-recv-302 [001] 515031.206008: skb_free_datagram_locked: skbaddr=f5b1d900Signed-off-by Koki Sanagi <[email protected]>--- include/trace/events/skb.h | 42 ++++++++++++++++++++++++++++++++++++++++++ net/core/datagram.c | 1 + net/core/dev.c | 2 ++ net/core/skbuff.c | 1 + 4 files changed, 46 insertions(+), 0 deletions(-)include/trace/events/skb.h +32
-0@@ -35,6 +35,48 @@ TRACE_EVENT(kfree_skb, __entry->skbaddr, __entry->protocol, __entry->location) ); +DECLARE_EVENT_CLASS (free_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb), + +TP_STRUCT__entry ( + __field( void *, skbaddr ) + ), + +TP_fast_assign ( + __entry->skbaddr = skb; + ), + +TP_printk ("skbaddr=%p" , __entry->skbaddr) + +); + +DEFINE_EVENT (free_skb, consume_skb, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); + +DEFINE_EVENT (free_skb, dev_kfree_skb_irq, + + TP_PROTO(struct sk_buff *skb), + + TP_ARGS(skb) +include/trace/events/skb.h TRACE_EVENT(kfree_skb, · line 79
Quoted 10 lines
include/trace/events/skb.h +10
-0+); + +DEFINE_EVENT (free_skb, skb_free_datagram_locked, + + TP_PROTO(struct sk_buff *skb), + +TP_ARGS (skb) + +); +Why create these last two tracepoints at all?
dev_kfree_skb_irqwill eventually pass throughkfree_skbanyway, getting picked up by the tracepoint there, the while the latter won't (since it uses__kfree_skbinstead), I think that could be fixed up by add a call totrace_kfree_skbthere directly, saving you two tracepoints.Quoted 6 lines
Quoted 2 lines
Neil
I think
dev_kfree_skb_irqisn't chased bytrace_kfree_skbortrace_consume_skbcompletely. Becausenet_tx_actionfrees skb by__kfree_skb. So it is better to addtrace_kfree_skbbefore it.skb_free_datagram_lockedis same.Quoted 8 lines
It isn't, you're right, but that was the point I made above. Those missed areas could be easily handled by adding calls to
trace_kfree_skbwhich already exists, to the missed areas. Then you don't need to create those new tracepoints. The way your doing this, if someone wants to trace all skb frees in debugfs, they would have to enable three tracepoints, not just one. Not that thats the point of your patch, but its something to consider, and it simplifies your code. Neil
Quoted 6 lines
O.K. I've re-made a patch to use
trace_kfree_skbinstead oftrace_dev_kfree_skb_irqandtrace_skb_free_datagram_locked.
But I've got a problem.
I should use not__builtin_return_address, but macro or function which returns current address. But I don't know any macro like that. Do you know any solution ?
Since the trace call is the first thing in the function, why not just pass in skb_free_datagram_locked as the pointer. That should work out properly Neil
Quoted 1 line
Re: [RFC PATCH v3 1/5] irq: add tracepoint to softirq_raise
In reply to Neil HormanQuoted 33 lines · KOSAKI Motohiro
Quoted 32 lines
Quoted 23 lines
Quoted 19 lines
Quoted 9 lines
Quoted 9 lines
#endif /*
_TRACE_IRQ_H*/kernel/softirq.c +0
-0@@ -215,9 +215,9 @@ restart:int prev_count =preempt_count ();kstat_incr_softirqs_this_cpu (h - softirq_vec);Quoted 9 lines
kernel/softirq.c restart: · line 220
Quoted 5 lines
kernel/softirq.c +2
-2-trace_softirq_entry (h, softirq_vec); +trace_softirq_entry (h - softirq_vec); h->action (h); -trace_softirq_exit (h, softirq_vec); +trace_softirq_exit (h - softirq_vec);You're loosing information here by reducing the numbers of parameters in this tracepoint. How many other tracepoint scripts rely on having both pointers handy? Why not just do the pointer math inside your tracehook instead?
Quoted 4 lines
In
__raise_softirq_irqoffmacro there is no method to refersoftirq_vec, so it can't use softirqDECLARE_EVENT_CLASSas is.
Currently, there is no script usingsoftirq_entryorsoftirq_exit.Quoted 5 lines
That shouldn't matter, just pass in NULL for
softirq_vecin__raise_softirq_irqoffas the second argument to the trace function. You may need to fix up the class definition so that the assignment or printk doesn't try to dereference that pointer when its NULL, but thats easy enough, and it avoids breaking any other perf scripts floating out there.please see 5 lines above. we already have 'h -
softirq_vec' calculation in this function. so, Sanagi-san's change don't makes any overhead.
Quoted 7 lines
Quoted 2 lines
So, if the overhead is zero, I'd prefer simplest tracepoint definition :)
I never complained about performance here, I complained about information loss. You have a tracepoint that provides two arguments here, and you're eliminating one of them. That will potentially break other users of this tracepoint. I understand we don't normally care about that with tracepoints as much, but if we can avoid it, why don't we?
I see. I have no objection.
Thanks.