Hi Steven,
On Mon, Oct 2, 2017 at 12:37 PM, Steven Rostedt wrote:
> On Mon, 2 Oct 2017 12:33:30 -0700
> Joel Fernandes wrote:
>
>
>> diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
>> index 5dd1272d1ab2..2a1af0dd9cc4 100644
>> --- a/include/linux/irqflags.h
>> +++ b/include/linu
On Mon, 2 Oct 2017 12:33:30 -0700
Joel Fernandes wrote:
> diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
> index 5dd1272d1ab2..2a1af0dd9cc4 100644
> --- a/include/linux/irqflags.h
> +++ b/include/linux/irqflags.h
> @@ -93,7 +93,9 @@
> #define local_irq_save(flags)
On Mon, Oct 2, 2017 at 12:23 PM, Joel Fernandes wrote:
> Hi Steven,
>
> On Sat, Sep 30, 2017 at 2:08 AM, Steven Rostedt wrote:
>> On Mon, 25 Sep 2017 17:23:00 -0700
>> Joel Fernandes wrote:
>>
>>> The trace_hardirqs_off API can be called even when IRQs are already
>>> off. This is unlike the tra
Hi Steven,
On Sat, Sep 30, 2017 at 2:08 AM, Steven Rostedt wrote:
> On Mon, 25 Sep 2017 17:23:00 -0700
> Joel Fernandes wrote:
>
>> The trace_hardirqs_off API can be called even when IRQs are already
>> off. This is unlike the trace_hardirqs_on which checks if IRQs are off
>> (atleast from some
On Mon, 25 Sep 2017 17:23:00 -0700
Joel Fernandes wrote:
> The trace_hardirqs_off API can be called even when IRQs are already
> off. This is unlike the trace_hardirqs_on which checks if IRQs are off
> (atleast from some callsites), here are the definitions just for
> reference [1]. I guess we co
Hi Steven, Peter,
I'm planning to make the following changes for the next rev, could you
let me know if you're Ok with it?
1. Drop the stop_critical_timings changes - previous patch was
generating the preempt_enable/disable events but they aren't "real"
events. Instead since we already have cpuid
On Mon, 25 Sep 2017 15:57:30 -0700
Joel Fernandes wrote:
> 2. This stuff is already a bit trace heavy, I prefer not to generate
> event every time the preempt count increases. Ofcourse filters but
> still then we have the filtering overhead for a usecase that I am not
> really targetting with thi
Hi Peter,
On Mon, Sep 25, 2017 at 1:34 AM, Peter Zijlstra wrote:
> On Fri, Sep 22, 2017 at 11:28:30AM -0700, Joel Fernandes wrote:
[...]
>> >> void start_critical_timings(void)
>> >> {
>> >> + if (this_cpu_read(tracing_preempt_cpu))
>> >> + trace_preempt_enable_rcuidle(CALLER_AD
On Mon, Sep 25, 2017 at 3:52 AM, Steven Rostedt wrote:
> On Mon, 25 Sep 2017 12:32:23 +0200
> Peter Zijlstra wrote:
>
>
>> > You mean you want to trace all calls to preempt and irq off even if
>> > preempt and irqs are already off?
>>
>> Sure, why not? This stuff naturally nests, and who is to sa
On Mon, 25 Sep 2017 12:32:23 +0200
Peter Zijlstra wrote:
> > You mean you want to trace all calls to preempt and irq off even if
> > preempt and irqs are already off?
>
> Sure, why not? This stuff naturally nests, and who is to say its not a
> useful thing to trace all of them?
>
> By also t
On Mon, Sep 25, 2017 at 06:15:28AM -0400, Steven Rostedt wrote:
> On Mon, 25 Sep 2017 10:34:32 +0200
> Peter Zijlstra wrote:
>
> > >
> > > grep-1041 [002] d..180.363455: preempt_disable:
> > > caller=_raw_spin_lock_irqsave+0x1d/0x40
> > > parent=add_wait_queue+0x15/0x50
> >
>
On Mon, 25 Sep 2017 10:34:32 +0200
Peter Zijlstra wrote:
> >
> > grep-1041 [002] d..180.363455: preempt_disable:
> > caller=_raw_spin_lock_irqsave+0x1d/0x40
> > parent=add_wait_queue+0x15/0x50
>
> I suppose that sort-of makes sense for the preempt-tracer, but its a
> weird th
On Fri, Sep 22, 2017 at 11:28:30AM -0700, Joel Fernandes wrote:
> >> + TP_printk("caller=%pF parent=%pF",
> >> + (void *)((unsigned long)(_stext) + __entry->caller_offs),
> >> + (void *)((unsigned long)(_stext) + __entry->parent_offs))
> >> +);
> >
> > So I don't get
Hi Peter,
On Fri, Sep 22, 2017 at 2:02 AM, Peter Zijlstra wrote:
> On Thu, Sep 21, 2017 at 06:50:24PM -0700, Joel Fernandes wrote:
>> +DECLARE_EVENT_CLASS(preemptirq_template,
>> +
>> + TP_PROTO(unsigned long ip, unsigned long parent_ip),
>> +
>> + TP_ARGS(ip, parent_ip),
>> +
>> + TP
On Thu, Sep 21, 2017 at 06:50:24PM -0700, Joel Fernandes wrote:
> +DECLARE_EVENT_CLASS(preemptirq_template,
> +
> + TP_PROTO(unsigned long ip, unsigned long parent_ip),
> +
> + TP_ARGS(ip, parent_ip),
> +
> + TP_STRUCT__entry(
> + __field(u32, caller_offs)
> + __
Preempt and irq trace events can be used for tracing the start and
end of an atomic section which can be used by a trace viewer like
systrace to graphically view the start and end of an atomic section and
correlate them with latencies and scheduling issues.
This also serves as a prelude to using s
16 matches
Mail list logo
