Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933767Ab1D2UPu (ORCPT ); Fri, 29 Apr 2011 16:15:50 -0400 Received: from smtp-out.google.com ([216.239.44.51]:6601 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752621Ab1D2UPs convert rfc822-to-8bit (ORCPT ); Fri, 29 Apr 2011 16:15:48 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=eMHq1o1JqvMY0oJatYCH3nm1TvwbuT1LxEtm5lrLQ0YGzMguY/iJGFvvF2VBQXkR3u ATONHMrJgsxO3MC+uLWw== MIME-Version: 1.0 In-Reply-To: References: <1303512981-26234-1-git-send-email-vnagarnaik@google.com> From: Vaibhav Nagarnaik Date: Fri, 29 Apr 2011 13:15:04 -0700 Message-ID: Subject: Re: [PATCH] trace: Add special x86 irq entry/exit tracepoints To: Thomas Gleixner Cc: Steven Rostedt , Ingo Molnar , Michael Rubin , David Sharp , linux-kernel@vger.kernel.org, x86@kernel.org, Jiaying Zhang Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3535 Lines: 88 On Thu, Apr 28, 2011 at 5:14 PM, Thomas Gleixner wrote: > On Fri, 22 Apr 2011, Vaibhav Nagarnaik wrote: >> ?#include >> ?#include >> @@ -857,7 +858,9 @@ void __irq_entry smp_apic_timer_interrupt(struct pt_regs *regs) >> ? ? ? ?*/ >> ? ? ? exit_idle(); >> ? ? ? irq_enter(); >> + ? ? trace_special_irq_entry(LOCAL_TIMER_VECTOR); > > Gah. trace_special_irq is the worst name you could come up with. It's > tracing a vector which is nothing special and nothing x86 specific. > I will change it to trace_irq_vector_{entry|exit}. >> ?#include >> ?#include >> @@ -26,6 +27,8 @@ >> ?volatile unsigned long __jiffies __section_jiffies = INITIAL_JIFFIES; >> ?#endif >> >> +static struct irqaction *irq0_action; >> + > > Ouch! You need an extra pointer for that ? Moving the stupid irq0 > struct up a few lines would do the trick as well, right ? > Sure. I will update it. >> --- a/include/trace/events/irq.h >> +++ b/include/trace/events/irq.h >> @@ -139,6 +139,74 @@ DEFINE_EVENT(softirq, softirq_raise, >> ? ? ? TP_ARGS(vec_nr) >> ?); >> >> +#ifdef CONFIG_X86 >> +#include >> +#define special_irq_name(sirq) { sirq, #sirq } >> +#define show_special_irq_name(val) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ >> + ? ? __print_symbolic(val, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(NMI_VECTOR), ? ? ? ? ? ? ? ? ?\ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(LOCAL_TIMER_VECTOR), ? ? ? ? ?\ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(ERROR_APIC_VECTOR), ? ? ? ? ? \ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(RESCHEDULE_VECTOR), ? ? ? ? ? \ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(CALL_FUNCTION_VECTOR), ? ? ? ?\ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(CALL_FUNCTION_SINGLE_VECTOR), \ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(THERMAL_APIC_VECTOR), ? ? ? ? \ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(THRESHOLD_APIC_VECTOR), ? ? ? \ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(REBOOT_VECTOR), ? ? ? ? ? ? ? \ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(SPURIOUS_APIC_VECTOR), ? ? ? ?\ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(IRQ_WORK_VECTOR), ? ? ? ? ? ? \ >> + ? ? ? ? ? ? ? ? ? ? ?special_irq_name(X86_PLATFORM_IPI_VECTOR) ? ? ?\ >> + ? ? ? ? ? ? ? ? ? ? ) >> + >> +#define IS_INVALIDATE_TLB_VECTOR(__irq) (\ >> + ? ? ? ? ? ? __irq >= INVALIDATE_TLB_VECTOR_START && \ >> + ? ? ? ? ? ? __irq <= INVALIDATE_TLB_VECTOR_END) > > No way, really. > > Interrupt vectors are not x86 specific and they do no need any > architecture specific handling at all. > > The symbolic printout is a nice to have extra, but it can be solved by > providing an arch specific lookup table which does not require any of > that #ifdef X86 mess. If the table does not exist, then you simply can > print the vector number and be done with it. > I have changed that and now just include the asm/irq_vectors.h so other architectures can provide the look up table definitions in their respective files. I have also updated the description to address the use case. We can know when the system is moving between kernel and user spaces. How much time is being spent for operations and how it affects the running processes. > Thanks, > > ? ? ? ?tglx > Vaibhav Nagarnaik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/