From: Frederic Weisbecker <fweisbec@gmail.com>
To: Vaibhav Nagarnaik <vnagarnaik@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Michael Rubin <mrubin@google.com>,
David Sharp <dhsharp@google.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Jiaying Zhang <jiayingz@google.com>
Subject: Re: [PATCH v3] trace: Add x86 irq vector entry/exit tracepoints
Date: Fri, 8 Jul 2011 01:34:57 +0200 [thread overview]
Message-ID: <20110707233453.GE21115@somewhere> (raw)
In-Reply-To: <1308681903-12840-1-git-send-email-vnagarnaik@google.com>
On Tue, Jun 21, 2011 at 11:45:03AM -0700, Vaibhav Nagarnaik wrote:
> From: Jiaying Zhang <jiayingz@google.com>
>
> The current interrupt trace of irq_handler_entry and irq_handler_exit
> give traces of when an interrupt is handled. They provide good data
> about when the system is running in kernel space and how it affects the
> currently running applications.
>
> Apart from this, they are IRQ vectors which trigger the system into
> kernel space. Tracing such events gives us the trace of where the system
> is spending its time. We want to know which cores are handling
> interrupts and how they are affecting other processes in the system.
> Also, the trace provides information about when the cores are idle and
> which interrupts are changing that state.
>
> The following patch adds the event definition and trace instrumentation
> for interrupt vectors. A lookup table is provided to print out readable
> IRQ vector names. Apart from the IRQ vectors handled in the generic
> kernel code, some x86 specific IRQ vectors are also traced. The lookup
> table can be extended by adding other arch-specific IRQ vectors.
>
> Changelog:
> v2-v3
> * Move the irq_vector_{entry|exit} tracepoints back under irq/ sub
> folder
> * Trace the common IRQs in generic kernel code so that all archs can
> benefit.
>
> v1-v2
> * Move the irq_vector_{entry|exit} tracepoints under irq_vectors/ sub
> folder
>
> Signed-off-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
> ---
> arch/x86/kernel/apic/apic.c | 4 ++
> arch/x86/kernel/cpu/mcheck/therm_throt.c | 2 +
> arch/x86/kernel/cpu/mcheck/threshold.c | 2 +
> arch/x86/kernel/irq.c | 4 ++
> arch/x86/kernel/time.c | 16 ++++--
> arch/x86/kernel/traps.c | 3 +
> arch/x86/mm/tlb.c | 2 +
> include/trace/events/irq.h | 84 ++++++++++++++++++++++++++++++
> kernel/hrtimer.c | 6 ++
> kernel/irq_work.c | 4 ++
> kernel/sched.c | 4 ++
> kernel/smp.c | 5 ++
> kernel/time/tick-broadcast.c | 16 +++++-
> kernel/time/tick-common.c | 8 +++-
> kernel/time/tick-sched.c | 4 ++
> 15 files changed, 155 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index b9338b8..159851c 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1792,6 +1792,7 @@ void smp_spurious_interrupt(struct pt_regs *regs)
>
> exit_idle();
> irq_enter();
> + trace_irq_vector_entry(TRACE_SPURIOUS_APIC_VECTOR);
> /*
> * Check if this really is a spurious interrupt and ACK it
> * if it is a vectored one. Just in case...
> @@ -1806,6 +1807,7 @@ void smp_spurious_interrupt(struct pt_regs *regs)
> /* see sw-dev-man vol 3, chapter 7.4.13.5 */
> pr_info("spurious APIC interrupt on CPU#%d, "
> "should never happen.\n", smp_processor_id());
> + trace_irq_vector_exit(TRACE_SPURIOUS_APIC_VECTOR);
> irq_exit();
> }
>
Seems a lot of these tracepoints fit under that pattern:
irq_enter();
+ trace_irq_entry_entry(foo)
do things
+ trace_irq_exit(foo)
irq_exit();
What if we instead had trace_irq_enter() inside irq_enter() and
trace_irq_exit() inside irq_exit() ?
Then your specific irq tracepoints would just be one thing that inform us
about the nature of the interrupt:
irq_enter();
+ trace_irq_vector_entry(foo);
do things
irq_exit();
Those who are only interested in knowing when we have irqs can just turn
on trace_irq_enter() and trace_irq_exit().
Those who want more details about the nature of these interrupts can turn
on trace_irq_vector() and trace_irq_exit().
So you don't need the trace_irq_vector_exit anymore.
How does that sound?
> diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
> index 00cbb27..9179dca 100644
> --- a/arch/x86/kernel/time.c
> +++ b/arch/x86/kernel/time.c
> @@ -13,6 +13,7 @@
> #include <linux/interrupt.h>
> #include <linux/time.h>
> #include <linux/mca.h>
> +#include <trace/events/irq.h>
>
> #include <asm/vsyscall.h>
> #include <asm/x86_init.h>
> @@ -51,6 +52,13 @@ unsigned long profile_pc(struct pt_regs *regs)
> }
> EXPORT_SYMBOL(profile_pc);
>
> +static irqreturn_t timer_interrupt(int irq, void *dev_id);
> +static struct irqaction irq0 = {
> + .handler = timer_interrupt,
> + .flags = IRQF_DISABLED | IRQF_NOBALANCING | IRQF_IRQPOLL | IRQF_TIMER,
> + .name = "timer"
> +};
> +
> /*
> * Default timer interrupt handler for PIT/HPET
> */
> @@ -59,7 +67,9 @@ static irqreturn_t timer_interrupt(int irq, void *dev_id)
> /* Keep nmi watchdog up to date */
> inc_irq_stat(irq0_irqs);
>
> + trace_irq_handler_entry(irq, &irq0);
> global_clock_event->event_handler(global_clock_event);
> + trace_irq_handler_exit(irq, &irq0, 1);
Seems it should go to generic event handlers in kernel/time ?
> diff --git a/include/trace/events/irq.h b/include/trace/events/irq.h
> index 4fc1205..d2f3f1f 100644
> --- a/include/trace/events/irq.h
> +++ b/include/trace/events/irq.h
> @@ -138,6 +138,90 @@ DEFINE_EVENT(softirq, softirq_raise,
> TP_ARGS(vec_nr)
> );
>
> +#if !defined(_TRACE_IRQ_VECTOR_ENUM)
> +#define _TRACE_IRQ_VECTOR_ENUM
> +enum {
> + TRACE_NMI_VECTOR,
> + TRACE_NOHZ_TIMER_VECTOR,
> + TRACE_HRTIMER_VECTOR,
> + TRACE_ONESHOT_TIMER_VECTOR,
> + TRACE_PERIODIC_TIMER_BROADCAST_VECTOR,
> + TRACE_PERIODIC_TIMER_VECTOR,
> + TRACE_ERROR_APIC_VECTOR,
> + TRACE_RESCHEDULE_VECTOR,
> + TRACE_CALL_FUNCTION_VECTOR,
> + TRACE_CALL_FUNCTION_SINGLE_VECTOR,
> + TRACE_THERMAL_APIC_VECTOR,
> + TRACE_THRESHOLD_APIC_VECTOR,
> + TRACE_REBOOT_VECTOR,
> + TRACE_SPURIOUS_APIC_VECTOR,
> + TRACE_IRQ_WORK_VECTOR,
> + TRACE_X86_PLATFORM_IPI_VECTOR,
> + TRACE_INVALIDATE_TLB_VECTOR,
> +};
> +#endif
Pure x86 things shouldn't be in a generic header.
include/trace/event/irq.h should contain generic things. And I'm not sure
we want some generalized vector namespace for that but rather single contained
tracepoint names that make sense:
trace_ipi_function(), trace_irq_reschedule()...
But vector namespace makes sense for archs yeah.
> /* This part must be outside protection */
> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
> index a9205e3..84a0c70 100644
> --- a/kernel/hrtimer.c
> +++ b/kernel/hrtimer.c
> @@ -48,6 +48,7 @@
>
> #include <asm/uaccess.h>
>
> +#include <trace/events/irq.h>
> #include <trace/events/timer.h>
>
> /*
> @@ -1244,6 +1245,8 @@ void hrtimer_interrupt(struct clock_event_device *dev)
> ktime_t expires_next, now, entry_time, delta;
> int i, retries = 0;
>
> + trace_irq_vector_entry(TRACE_HRTIMER_VECTOR);
> +
> BUG_ON(!cpu_base->hres_active);
> cpu_base->nr_events++;
> dev->next_event.tv64 = KTIME_MAX;
> @@ -1316,6 +1319,7 @@ retry:
> if (expires_next.tv64 == KTIME_MAX ||
> !tick_program_event(expires_next, 0)) {
> cpu_base->hang_detected = 0;
> + trace_irq_vector_exit(TRACE_HRTIMER_VECTOR);
> return;
> }
>
> @@ -1355,6 +1359,8 @@ retry:
> tick_program_event(expires_next, 1);
> printk_once(KERN_WARNING "hrtimer: interrupt took %llu ns\n",
> ktime_to_ns(delta));
> +
> + trace_irq_vector_exit(TRACE_HRTIMER_VECTOR);
We already have hrtimer tracepoints.
next prev parent reply other threads:[~2011-07-07 23:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-22 22:56 [PATCH] trace: Add special x86 irq entry/exit tracepoints Vaibhav Nagarnaik
2011-04-25 23:41 ` Vaibhav Nagarnaik
2011-04-28 23:16 ` Vaibhav Nagarnaik
2011-04-28 23:41 ` Steven Rostedt
2011-04-29 20:12 ` [PATCH] trace: Add x86 irq vector " Vaibhav Nagarnaik
2011-04-29 20:26 ` Thomas Gleixner
2011-04-29 22:04 ` Vaibhav Nagarnaik
2011-05-31 21:28 ` [PATCH v2] " Vaibhav Nagarnaik
2011-06-01 0:00 ` Frederic Weisbecker
2011-06-01 22:38 ` Vaibhav Nagarnaik
2011-06-01 23:30 ` David Sharp
2011-06-16 3:02 ` Frederic Weisbecker
2011-06-21 18:43 ` Vaibhav Nagarnaik
2011-07-06 23:43 ` H. Peter Anvin
2011-07-06 23:56 ` Frederic Weisbecker
2011-07-07 0:02 ` H. Peter Anvin
2011-07-07 0:25 ` Frederic Weisbecker
2011-07-07 0:30 ` H. Peter Anvin
2011-07-07 0:51 ` Frederic Weisbecker
2011-07-07 9:57 ` Ingo Molnar
2011-07-07 22:50 ` David Sharp
2011-07-07 23:00 ` Frederic Weisbecker
2011-06-21 18:45 ` [PATCH v3] " Vaibhav Nagarnaik
2011-07-06 21:50 ` Vaibhav Nagarnaik
2011-07-06 23:38 ` Andi Kleen
2011-07-07 23:34 ` Frederic Weisbecker [this message]
2011-07-08 0:54 ` David Sharp
2011-07-11 15:54 ` Frederic Weisbecker
2011-07-11 18:21 ` Vaibhav Nagarnaik
2011-07-12 18:09 ` Frederic Weisbecker
2011-07-12 22:08 ` Vaibhav Nagarnaik
2011-07-13 14:11 ` Frederic Weisbecker
2011-07-13 18:18 ` Vaibhav Nagarnaik
2011-04-29 0:14 ` [PATCH] trace: Add special x86 irq " Thomas Gleixner
2011-04-29 20:15 ` Vaibhav Nagarnaik
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=20110707233453.GE21115@somewhere \
--to=fweisbec@gmail.com \
--cc=dhsharp@google.com \
--cc=jiayingz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mrubin@google.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vnagarnaik@google.com \
--cc=x86@kernel.org \
/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