[RFC] media: v4l2: Adding mem2mem ftrace support

* [RFC] media: v4l2: Adding mem2mem ftrace support
@ 2021-05-17 18:37 Emil Velikov
  2021-05-17 18:37 ` [PATCH 1/5] media: v4l2: print the fh, during qbuf/dqbuf tracing Emil Velikov
                   ` (5 more replies)
  0 siblings, 6 replies; 9+ messages in thread
From: Emil Velikov @ 2021-05-17 18:37 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Hans Verkuil, Ezequiel Garcia,
	Philipp Zabel, Alexandre Courbot, Mikhail Ulyanov, kernel
  Cc: linux-media

Hi everyone,

This RFC aims to kick off a discussion about adding ftrace events in
V4L2 and mem2mem in particular.

The goal is to aid both userspace and kernel developers alike by
allowing them to trace their individual application/library and drivers,
respectively.

# Data provided

In order to correlate the components through their lifetime we need a
few unique identifiers:

 - minor: the device minor, aka /dev/video
   Useful, when multiple devices are present.

 - fh: file handle
   Allows us to map the buffer, ioctl and mem2mem jobs.

 - fh: as a job instance... sort of
   We also use it as to distinguish between the different jobs, as long
   as we track the cancel/finish events.

Additionally, for buffers we need:
 - type: VIDEO_OUTPUT_MPLANE, VIDEO_CAPTURE_MPLANE, etc
 - index: buffer index
   Each buffer type has its own pool.

# Event list and examples

Generic:

v4l2_ioctl_s_fmt: minor = 0, fh = 5068c670, type = VIDEO_OUTPUT_MPLANE,
width=1280, height=720, ...

v4l2_qbuf: minor = 0, fh = 5068c670, index = 0, type =
VIDEO_CAPTURE_MPLANE, bytesused = 0, ...
v4l2_dqbuf: minor = 0, fh = 5068c670, index = 0, type =
VIDEO_CAPTURE_MPLANE, bytesused = 0, ...

Mem2mem specific:

v4l2_m2m_schedule: minor = 0, fh = 5068c670
v4l2_m2m_schedule_failed: minor = 0, fh = 5068c670, reason = NO_SRC
v4l2_m2m_queue_job: minor = 0, fh = 5068c670, src = 0, dst = 0
Currently src and dst only show the buffer index. Buffer type can be
deduced based on the type of job - encode or decode.

v4l2_m2m_run_job: minor = 0, fh = 5068c670
v4l2_m2m_cancel_job: minor = 0, fh = 5068c670
v4l2_m2m_finish_job: minor = 0, fh = 5068c670

v4l2_m2m_stream_on: minor = 0, fh = 5068c670, type = f9e16c2e
v4l2_m2m_stream_off: minor = 0, fh = 5068c670, type = f9e16c2e

v4l2_m2m_buf_done: minor = 0, fh = 5068c670, index = 0, type =
VIDEO_CAPTURE_MPLANE, state = DONE

# Testing and feasibility

While developing this series I've used them against the recent SAMA5D4
Hantro driver. As result I was able to measure:

 - No time differences when switching from hard to soft IRQ
 - Seemingly gstreamer issues decoding jobs, even before it has queued
   any buffers.
 - Notable 1ms queue times, when using gstreamer's new decodebin3
   element - relative to 50us when using decodebin.

# Open questions

As you may have noticed, a couple of places are not so friendly to
scripting and external tools. Here is what we can do:
 - add additional mem2mem job index identifier, so we can parse traces
   without having to track v4l2_m2m_cancel_job or v4l2_m2m_finish_job.
 - expand v4l2_m2m_queue_job() to include mode buffer details
   {src,dst}_buf { .index = foo, .type = bar, ... }

Thus looking for feedback from the overall community - is this something
we want, do the proposed trace events seem sufficient for your use-case?

Comments and reviews for the individual patches is more than welcome.

Thanks
Emil

Emil Velikov (5):
  media: v4l2: print the fh, during qbuf/dqbuf tracing
  media: v4l2: add VIDIOC_S_FMT tracing
  media: v4l2-mem2mem: add job tracing
  media: v4l2-mem2mem: add v4l2_m2m_buf_done trace point
  media: v4l2-mem2mem: add v4l2_m2m_stream_on/off tracepoints

 drivers/media/v4l2-core/v4l2-ioctl.c   |  12 +-
 drivers/media/v4l2-core/v4l2-mem2mem.c |  26 ++
 drivers/media/v4l2-core/v4l2-trace.c   |  11 +
 include/media/v4l2-mem2mem.h           |  21 +-
 include/trace/events/v4l2.h            | 357 ++++++++++++++++++++++++-
 include/uapi/linux/videodev2.h         |   1 +
 6 files changed, 411 insertions(+), 17 deletions(-)

-- 
2.31.1

^ permalink raw reply	[flat|nested] 9+ messages in thread