All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Jiaying Zhang <jiayingz@google.com>
Subject: Re: [PATCH v2] trace: Add x86 irq vector entry/exit tracepoints
Date: Wed, 1 Jun 2011 02:00:00 +0200	[thread overview]
Message-ID: <20110531235957.GB5256@somewhere.redhat.com> (raw)
In-Reply-To: <1306877298-31713-1-git-send-email-vnagarnaik@google.com>

On Tue, May 31, 2011 at 02:28:18PM -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. For x86, a lookup table is provided to print out
> readable IRQ vector names. The template can be used to provide interrupt
> vector lookup tables on other architectures.
> 
> With this patch, following interrupt vectors are logged by ftrace
> (when enabled):
> 
> Interrupt as in /proc/interrupts        Name as it appears in ftrace log
> NMI: Non-maskable interrupts           : NMI_VECTOR
> LOC: Local timer interrupts            : LOCAL_TIMER_VECTOR
> SPU: Spurious interrupts               : SPURIOUS_APIC_VECTOR
> PMI: Performance monitoring interrupts : <not added>
> IWI: IRQ work interrupts               : IRQ_WORK_VECTOR
> RES: Rescheduling interrupts           : RESCHEDULE_VECTOR
> CAL: Function call interrupts          : CALL_FUNCTION_VECTOR or
>                                          CALL_FUNCTION_SINGLE_VECTOR
> TLB: TLB shootdowns                    : INVALIDATE_TLB_VECTOR_START to
>                                          INVALIDATE_TLB_VECTOR_END
> TRM: Thermal event interrupts          : THERMAL_APIC_VECTOR
> THR: Threshold APIC interrupts         : THRESHOLD_APIC_VECTOR
> MCE: Machine check exceptions          : <not added>
> MCP: Machine check polls               : <not added>
> ERR:                                   : ERROR_APIC_VECTOR
> MIS:                                   : <not added>
> PLT: Platform interrupts               : X86_PLATFORM_IPI_VECTOR
> 
> $ sh ~/ftrace_test.sh
> tracing...
>   cpu0: overrun: 0
>   cpu1: overrun: 0
>   cpu2: overrun: 0
>   cpu3: overrun: 0
> IRQ ftrace record counts (ignoring numeric  irq=(0|1|4|5|7|9|10|24) )
>       2 irq=242 name=INVALIDATE_TLB_VECTOR_2
>       3 irq=252 name=CALL_FUNCTION_VECTOR
>       6 irq=241 name=INVALIDATE_TLB_VECTOR_1
>       6 irq=2 name=NMI_VECTOR
>      22 irq=240 name=INVALIDATE_TLB_VECTOR_0
>      40 irq=251 name=CALL_FUNCTION_SINGLE_VECTOR
>     587 irq=253 name=RESCHEDULE_VECTOR
>   15013 irq=239 name=LOCAL_TIMER_VECTOR
> /proc/interrupts stats difference
>       6 NMI (Non-maskable interrupts)
>   14945 LOC (Local timer interrupts)
>       6 PMI (Performance monitoring interrupts)
>     578 RES (Rescheduling interrupts)
>      42 CAL (Function call interrupts)
>      30 TLB (TLB shootdowns)
>       4 MCP (Machine check polls)
> 
> In above output:
> NMI (Non-maskable interrupts) == NMI_VECTOR (irq 2)
> LOC (Local timer interrupts) == LOCAL_TIMER_VECTOR (irq 239)
> RES (Rescheduling interrupts) == RESCHEDULE_VECTOR (irq=253)
> CAL (Function call interrupts) == CALL_FUNCTION_VECTOR (irq 252) +
>                                   CALL_FUNCTION_SINGLE_VECTOR (irq 251)
> TLB (TLB shootdowns) == INVALIDATE_TLB_VECTOR_0 (irq=240) +
>                         INVALIDATE_TLB_VECTOR_1 (irq=241) +
>                         INVALIDATE_TLB_VECTOR_2 (irq=242)
> 
> Signed-off-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
> ---
> Changelog:
> v1-v2
> * Move the irq_vector_{entry|exit} tracepoints under irq_vectors/ sub
>   folder
> * Rebased to 3.0.0
> 
>  arch/x86/include/asm/irq_vectors.h       |   50 ++++++++++++++++++++++++++
>  arch/x86/kernel/apic/apic.c              |    7 ++++
>  arch/x86/kernel/cpu/mcheck/therm_throt.c |    3 ++
>  arch/x86/kernel/cpu/mcheck/threshold.c   |    3 ++
>  arch/x86/kernel/irq.c                    |    7 +++-
>  arch/x86/kernel/irq_work.c               |    3 ++
>  arch/x86/kernel/smp.c                    |    7 ++++
>  arch/x86/kernel/time.c                   |   16 +++++---
>  arch/x86/kernel/traps.c                  |    3 ++
>  arch/x86/mm/tlb.c                        |    3 ++
>  include/trace/events/irq_vectors.h       |   56 ++++++++++++++++++++++++++++++
>  11 files changed, 151 insertions(+), 7 deletions(-)
>  create mode 100644 include/trace/events/irq_vectors.h
> 
> diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
> index 6e976ee..af06349 100644
> --- a/arch/x86/include/asm/irq_vectors.h
> +++ b/arch/x86/include/asm/irq_vectors.h
> @@ -182,4 +182,54 @@ static inline int invalid_vm86_irq(int irq)
>  # define NR_IRQS			NR_IRQS_LEGACY
>  #endif
>  
> +#define irq_vector_name(sirq) { sirq, #sirq }
> +#define invalidate_tlb_vector_name(i) { INVALIDATE_TLB_VECTOR_END-31+i, \
> +					"INVALIDATE_TLB_VECTOR" }

IIRC, Thomas suggested in the v1 to turn arch tracepoints into core ones when they
stand for generic (ie: shared by all archs) event meaning.

I don't know where the discussion went after that, but that still seems to
me an important direction. Tracing irqs by their vector number should be reserved
for pure arch meanings. Sharing common tracepoints for generic events amongst archs makes life
easier for tools. Bonus when the tracepoint can be placed in the generic code.


> +#define irq_vector_name_table						\
> +			irq_vector_name(NMI_VECTOR),			\
> +			irq_vector_name(LOCAL_TIMER_VECTOR),		\

This should be a tracepoint in the generic timer interrupt handler(s).

> +			irq_vector_name(ERROR_APIC_VECTOR),		\
> +			irq_vector_name(RESCHEDULE_VECTOR),		\

Although each archs have their own implementations of rescheduling interrupt,
it's a common event amongst arch. Better have a common tracepoint for that
and not a different vector number between them.

> +			irq_vector_name(CALL_FUNCTION_VECTOR),		\
> +			irq_vector_name(CALL_FUNCTION_SINGLE_VECTOR),	\

Both should be tracepoints in kernel/smp.c: generic_smp_call_function_*_interrupt()

> +			irq_vector_name(THERMAL_APIC_VECTOR),		\
> +			irq_vector_name(THRESHOLD_APIC_VECTOR),		\
> +			irq_vector_name(REBOOT_VECTOR),			\

Reboot seems to be generic as well.

> +			irq_vector_name(SPURIOUS_APIC_VECTOR),		\
> +			irq_vector_name(IRQ_WORK_VECTOR),		\

Should be in the irq work generic code.

  reply	other threads:[~2011-06-01  0:00 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 [this message]
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
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=20110531235957.GB5256@somewhere.redhat.com \
    --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.