Prev: staging:et131x:et131x_isr.c Fix coding style issues. This patch fixes line length and brace coding style issues raised by checkpatch.pl Signed-off-by: Michael Tate <michael.tate@wanadoo.fr>
Next: Infinite loop on boot in free_early_partial due to start==end on tip/master
From: Masami Hiramatsu on 5 Mar 2010 10:10 Frederic Weisbecker wrote: > Events that trigger overflows by interrupting a context can > use get_irq_regs() or task_pt_regs() to retrieve the state > when the event triggered. But this is not the case for some > other class of events like trace events as tracepoints are > executed in the same context than the code that triggered > the event. > > It means we need a different api to capture the regs there, > namely we need a hot snapshot to get the most important > informations for perf: the instruction pointer to get the > event origin, the frame pointer for the callchain, the code > segment for user_mode() tests (we always use __KERNEL_CS as > trace events always occur from the kernel) and the eflags > for further purposes. > > Signed-off-by: Frederic Weisbecker <fweisbec(a)gmail.com> > Cc: Ingo Molnar <mingo(a)elte.hu> > Cc: Thomas Gleixner <tglx(a)linutronix.de> > Cc: H. Peter Anvin <hpa(a)zytor.com> > Cc: Peter Zijlstra <peterz(a)infradead.org> > Cc: Paul Mackerras <paulus(a)samba.org> > Cc: Steven Rostedt <rostedt(a)goodmis.org> > Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> > Cc: Masami Hiramatsu <mhiramat(a)redhat.com> > Cc: Jason Baron <jbaron(a)redhat.com> > Cc: Archs <linux-arch(a)vger.kernel.org> > --- > arch/x86/kernel/cpu/perf_event.c | 12 ++++++++++ > arch/x86/kernel/dumpstack.h | 15 +++++++++++++ > include/linux/perf_event.h | 42 +++++++++++++++++++++++++++++++++++++- > kernel/perf_event.c | 5 ++++ > 4 files changed, 73 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c > index 641ccb9..274d0cd 100644 > --- a/arch/x86/kernel/cpu/perf_event.c > +++ b/arch/x86/kernel/cpu/perf_event.c > @@ -1662,6 +1662,18 @@ struct perf_callchain_entry *perf_callchain(struct pt_regs *regs) > return entry; > } > > +void perf_arch_save_regs(struct pt_regs *regs, unsigned long ip, int skip) Hmm, why would you call it 'save_regs' ? It seems that this function is just for fixing registers instead of saving it into somewhere... Thank you, -- Masami Hiramatsu e-mail: mhiramat(a)redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Masami Hiramatsu on 5 Mar 2010 12:10
Frederic Weisbecker wrote: > On Fri, Mar 05, 2010 at 10:08:07AM -0500, Masami Hiramatsu wrote: >>> +void perf_arch_save_regs(struct pt_regs *regs, unsigned long ip, int skip) >> >> Hmm, why would you call it 'save_regs' ? >> It seems that this function is just for fixing registers >> instead of saving it into somewhere... >> >> Thank you, > > > Hmm, save_regs() describes what it does: you pass > a pt_regs and it saves registers inside. But it > has also a kind of fixup thing as it also rewinds. Ah, I see. so this saves current register values into pt_regs. :) > > I'm not sure using a fixup thing for the naming > is correct as we are not starting with initial > regs passed to the function (just a raw buffer). > > What about perf_save_caller_regs() ? > Hmm, I think, it might be better perf_get_caller_regs() or something like that (fetch ?). Thank you, -- Masami Hiramatsu e-mail: mhiramat(a)redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |