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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.