mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Claudio <claudio.fontana@gliwa.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: new arch-independent tracepoints on hardware entry/exit from interrupt ?
Date: Mon, 29 Oct 2018 08:58:50 +0100	[thread overview]
Message-ID: <a2e9ee60-e206-3775-62db-c05dc046b15e@gliwa.com> (raw)


Hello,

I am currently facing the requirements to trace OS events close to hardware entry and exit from
interrupt.

There are currently arch-independent events defined for entry/exit from irq handlers as
registered in Linux (irq_handler_entry, irq_handler_exit),

However that is of course a different view compared with the entry and exit to/from the kernel from a hardware perspective.

While playing around with the idea, I experimented with the idea of having two new events:

name: hw_irq_entry
ID: 93
format:
	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
	field:unsigned char common_preempt_count;	offset:3;	size:1;signed:0;
	field:int common_pid;	offset:4;	size:4;	signed:1;

	field:irq_hw_number_t hw_irq;	offset:8;	size:8;	signed:0;

print fmt: "hw_irq=%lu", REC->hw_irq

name: hw_irq_exit
ID: 92
format:
	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
	field:unsigned char common_preempt_count;	offset:3;	size:1;signed:0;
	field:int common_pid;	offset:4;	size:4;	signed:1;

	field:irq_hw_number_t hw_irq;	offset:8;	size:8;	signed:0;

print fmt: "hw_irq=%lu", REC->hw_irq

With the intention to report on any architecture the specific number meaningful for that architecture.

I noticed that on x86 we have a specific separate events for irq_vectors,
apparently introduced by commit cf910e83ae23 ("x86, trace: Add irq vector tracepoints")

but I wonder if a more general solution could be implemented to cover meaningfully all architectures,
without having the tools having to special case all possible architectures and also special case all possible events generated as a consequence of irq entry.

The use case here is about timing analysis for the automotive domain, the current architectures we are looking at are x86 and arm64.

Thank you for your thoughts on this,

Claudio

                 reply	other threads:[~2018-10-29  8:07 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a2e9ee60-e206-3775-62db-c05dc046b15e@gliwa.com \
    --to=claudio.fontana@gliwa.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®