search for: tracepoint

To help in vhost analyzing, the following series adding basic tracepoints to vhost. Operations of both virtqueues and vhost works were traced in current implementation, net code were untouched. A top-like satistics displaying script were introduced to help the troubleshooting. TODO: - net specific tracepoints? --- Jason Wang (2): vhost: basic tracepoints...

To help in vhost analyzing, the following series adding basic tracepoints to vhost. Operations of both virtqueues and vhost works were traced in current implementation, net code were untouched. A top-like satistics displaying script were introduced to help the troubleshooting. TODO: - net specific tracepoints? --- Jason Wang (2): vhost: basic tracepoints...

Recent debugging on vhost net zerocopy shows the need of tracepoints. So to help in vhost{net} debugging and performance analyzing, the following series adding basic tracepoints to vhost. Operations of both vhost and vhost_net were traced in current implementation. A top-like satistics displaying script were introduced to help the troubleshooting: vhost statistics...

Recent debugging on vhost net zerocopy shows the need of tracepoints. So to help in vhost{net} debugging and performance analyzing, the following series adding basic tracepoints to vhost. Operations of both vhost and vhost_net were traced in current implementation. A top-like satistics displaying script were introduced to help the troubleshooting: vhost statistics...

Hi, I''m posting a question hoping someone will know the answer off hand thereby reducing my search time. :-) With USDT probes, the tracepoint is only installed by libdtrace itself, never by the drti ioctl. So whenever I run a program with an USDT probe, no tracepoint is installed. Only after I run the dtrace command the tracepoint is actually installed on the victim process. My question is about how Solaris discovers the correct instruc...

We use set_bit() to assign ordered extent''s flags, but in the related tracepoint we don''t do the same thing, which makes the trace output not to parse flags correctly. Also, since the flags are bits stuff, we change to use __print_flags with a ''delim'' instead of __print_symbolic. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> --- include/trace/...

...he address family field, but it might not be obvious. Plus the IPv4-mapped IPv6 addresses are not really formatted as IPv4, though yeah, IPv4 notation is embedded in that. All the information is still there, but... scrambled? Not sure the reduction in clarity is worth the 8 bytes that we save. The tracepoint is unlikely to trigger often. What say you?

...nt_open(attr, pid, cpu, group_fd, flags): + return syscall(298, ctypes.pointer(attr), ctypes.c_int(pid), + ctypes.c_int(cpu), ctypes.c_int(group_fd), + ctypes.c_long(flags)) + +PERF_TYPE_HARDWARE = 0 +PERF_TYPE_SOFTWARE = 1 +PERF_TYPE_TRACEPOINT = 2 +PERF_TYPE_HW_CACHE = 3 +PERF_TYPE_RAW = 4 +PERF_TYPE_BREAKPOINT = 5 + +PERF_SAMPLE_IP = 1 << 0 +PERF_SAMPLE_TID = 1 << 1 +PERF_SAMPLE_TIME = 1 << 2 +PERF_SAMPLE_ADDR...

In the context of support not only IFunc but DTrace, what kind of features do you want to add to lld, if you have a chance to implement it in the linker instead of a post-processing tool? I wonder if we can solve both of your problems. On Thu, Aug 23, 2018 at 1:33 AM Mark Johnston <markj at freebsd.org> wrote: > On Wed, Aug 22, 2018 at 10:11:00AM -0400, Ed Maste wrote: > > On 22

...en.h new file mode 100644 index 0000000..cbe2dca --- /dev/null +++ b/include/trace/events/swiotlb-xen.h @@ -0,0 +1,46 @@ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM swiotlb-xen + +#if !defined(_TRACE_SWIOTLBXEN_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_SWIOTLBXEN_H + +#include <linux/tracepoint.h> + +TRACE_EVENT(bounced, + + TP_PROTO(struct device *dev, + dma_addr_t dev_addr, + size_t size, + int swiotlb_force), + + TP_ARGS(dev, dev_addr, size, swiotlb_force), + + TP_STRUCT__entry( + __string( dev_name, dev_name(dev) ) + __field( u64, dma_mask ) + __field( dma_addr_t, dev_add...

...en.h new file mode 100644 index 0000000..cbe2dca --- /dev/null +++ b/include/trace/events/swiotlb-xen.h @@ -0,0 +1,46 @@ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM swiotlb-xen + +#if !defined(_TRACE_SWIOTLBXEN_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_SWIOTLBXEN_H + +#include <linux/tracepoint.h> + +TRACE_EVENT(bounced, + + TP_PROTO(struct device *dev, + dma_addr_t dev_addr, + size_t size, + int swiotlb_force), + + TP_ARGS(dev, dev_addr, size, swiotlb_force), + + TP_STRUCT__entry( + __string( dev_name, dev_name(dev) ) + __field( u64, dma_mask ) + __field( dma_addr_t, dev_add...

...en.h new file mode 100644 index 0000000..cbe2dca --- /dev/null +++ b/include/trace/events/swiotlb-xen.h @@ -0,0 +1,46 @@ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM swiotlb-xen + +#if !defined(_TRACE_SWIOTLBXEN_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_SWIOTLBXEN_H + +#include <linux/tracepoint.h> + +TRACE_EVENT(bounced, + + TP_PROTO(struct device *dev, + dma_addr_t dev_addr, + size_t size, + int swiotlb_force), + + TP_ARGS(dev, dev_addr, size, swiotlb_force), + + TP_STRUCT__entry( + __string( dev_name, dev_name(dev) ) + __field( u64, dma_mask ) + __field( dma_addr_t, dev_add...

...letion even for zerocopy skbs? > This way if we suspect packets are delayed forever > somewhere, we can enable that and see guest networking block. > > Additionally, I think we should add a way to count zero copy > and non zero copy packets. > I see two ways to implement this: add tracepoints in vhost-net > or add counters in tun accessible with ethtool. > This can be a patch on top and does not have to block > this one though. > Yes, I post a RFC about 2 years ago, see https://lkml.org/lkml/2012/4/9/478 which only traces generic vhost behaviours. I can refresh this and ad...

...letion even for zerocopy skbs? > This way if we suspect packets are delayed forever > somewhere, we can enable that and see guest networking block. > > Additionally, I think we should add a way to count zero copy > and non zero copy packets. > I see two ways to implement this: add tracepoints in vhost-net > or add counters in tun accessible with ethtool. > This can be a patch on top and does not have to block > this one though. > Yes, I post a RFC about 2 years ago, see https://lkml.org/lkml/2012/4/9/478 which only traces generic vhost behaviours. I can refresh this and ad...

...his is because we don't reserve enough tailroom for struct skb_shared_info which breaks XDP assumption. So this patch fixes this by reserving enough tailroom and using fixed size of rx buffer. Signed-off-by: Jason Wang <jasowang at redhat.com> --- Changes from V1: - do not add duplicated tracepoint when redirection fails --- drivers/net/virtio_net.c | 54 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 42 insertions(+), 12 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 9bb9e56..426dcf7 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/...

...his is because we don't reserve enough tailroom for struct skb_shared_info which breaks XDP assumption. So this patch fixes this by reserving enough tailroom and using fixed size of rx buffer. Signed-off-by: Jason Wang <jasowang at redhat.com> --- Changes from V1: - do not add duplicated tracepoint when redirection fails --- drivers/net/virtio_net.c | 54 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 42 insertions(+), 12 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 9bb9e56..426dcf7 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/...

I''ve been trying to have all spice features working on xen domUs since the end of 2011. Basic functions were already working. Adding qemu parameters manually for vdagent and usbredirection was and is also working (I made the patches to support them directly on xl). Qxl was never working: one bug on xen and one on qemu about qxl are fixed, the other xen bug found months ago on the

Asm goto feature was introduces to GCC in order to optimize the support for tracepoints in Linux kernel (it can be used for other things that do nop patching). GCC documentation describes their motivating example here: https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gcc/Extended-Asm.html #define TRACE1(NUM) \ do {...

...hese packets. It might not be possible to implement some features, think of (AF_XDP) zero-copy. 2. This can easily cause out-of-order packets. 3. It makes it harder to troubleshoot, when diagnosing issues around #1, we have a hard time determining what path an XDP packet took (the xdp tracepoints doesn't know). [...] > @@ -590,25 +526,14 @@ static struct sk_buff *receive_small(struct net_device *dev, > if (unlikely(hdr->hdr.gso_type)) > goto err_xdp; > > + /* This happnes when headroom is not enough because > + * the buffer was refilled before XDP is...

...hese packets. It might not be possible to implement some features, think of (AF_XDP) zero-copy. 2. This can easily cause out-of-order packets. 3. It makes it harder to troubleshoot, when diagnosing issues around #1, we have a hard time determining what path an XDP packet took (the xdp tracepoints doesn't know). [...] > @@ -590,25 +526,14 @@ static struct sk_buff *receive_small(struct net_device *dev, > if (unlikely(hdr->hdr.gso_type)) > goto err_xdp; > > + /* This happnes when headroom is not enough because > + * the buffer was refilled before XDP is...