Milian Wolff writes:
>
> I agree. I personally like your suggested approach - only add an indication
> when the IP differs so much that it points to a different function. What do
> others say to this?
Yes that's fine.
-Andi
Milian Wolff writes:
>
> I agree. I personally like your suggested approach - only add an indication
> when the IP differs so much that it points to a different function. What do
> others say to this?
Yes that's fine.
-Andi
On Donnerstag, 15. November 2018 03:05:32 CET Travis Downs wrote:
> On Wed, Nov 14, 2018 at 8:20 AM Milian Wolff wrote:
> > 3) I suggest we always keep the first frame and sample IP from the user
> > regs, i.e. the accurate PEBS/IBS IP. Then we add the following frames
> > from unwinding the
On Donnerstag, 15. November 2018 03:05:32 CET Travis Downs wrote:
> On Wed, Nov 14, 2018 at 8:20 AM Milian Wolff wrote:
> > 3) I suggest we always keep the first frame and sample IP from the user
> > regs, i.e. the accurate PEBS/IBS IP. Then we add the following frames
> > from unwinding the
On Sun, Nov 11, 2018 at 10:26 PM Andi Kleen wrote:
> On Sat, Nov 10, 2018 at 09:50:05PM -0500, Travis Downs wrote:
> LBR is not part of PEBS, but is collected separately in the PMI handler.
Thanks for clearing this up - so you can ignore any earlier
suggestions on my part of trying to use LBR
On Sun, Nov 11, 2018 at 10:26 PM Andi Kleen wrote:
> On Sat, Nov 10, 2018 at 09:50:05PM -0500, Travis Downs wrote:
> LBR is not part of PEBS, but is collected separately in the PMI handler.
Thanks for clearing this up - so you can ignore any earlier
suggestions on my part of trying to use LBR
On Wed, Nov 14, 2018 at 8:20 AM Milian Wolff wrote:
> 3) I suggest we always keep the first frame and sample IP from the user regs,
> i.e. the accurate PEBS/IBS IP. Then we add the following frames from unwinding
> the ustack with the iregs.
Does this mean that the displayed unwind will
On Wed, Nov 14, 2018 at 8:20 AM Milian Wolff wrote:
> 3) I suggest we always keep the first frame and sample IP from the user regs,
> i.e. the accurate PEBS/IBS IP. Then we add the following frames from unwinding
> the ustack with the iregs.
Does this mean that the displayed unwind will
On Montag, 12. November 2018 04:26:37 CET Andi Kleen wrote:
> On Sat, Nov 10, 2018 at 09:50:05PM -0500, Travis Downs wrote:
> >On Sat, Nov 10, 2018 at 8:07 PM Andi Kleen wrote:
> > On Sat, Nov 10, 2018 at 04:42:48PM -0500, Travis Downs wrote:
> > > I guess this problem doesn't occur
On Montag, 12. November 2018 04:26:37 CET Andi Kleen wrote:
> On Sat, Nov 10, 2018 at 09:50:05PM -0500, Travis Downs wrote:
> >On Sat, Nov 10, 2018 at 8:07 PM Andi Kleen wrote:
> > On Sat, Nov 10, 2018 at 04:42:48PM -0500, Travis Downs wrote:
> > > I guess this problem doesn't occur
On Sat, Nov 10, 2018 at 09:50:05PM -0500, Travis Downs wrote:
>On Sat, Nov 10, 2018 at 8:07 PM Andi Kleen wrote:
>
> On Sat, Nov 10, 2018 at 04:42:48PM -0500, Travis Downs wrote:
> > I guess this problem doesn't occur for LBR unwinding since the LBR
> > records are captured at
On Sat, Nov 10, 2018 at 09:50:05PM -0500, Travis Downs wrote:
>On Sat, Nov 10, 2018 at 8:07 PM Andi Kleen wrote:
>
> On Sat, Nov 10, 2018 at 04:42:48PM -0500, Travis Downs wrote:
> > I guess this problem doesn't occur for LBR unwinding since the LBR
> > records are captured at
On Sat, Nov 10, 2018 at 8:07 PM Andi Kleen wrote:
>
> On Sat, Nov 10, 2018 at 04:42:48PM -0500, Travis Downs wrote:
> > I guess this problem doesn't occur for LBR unwinding since the LBR
> > records are captured at the same
> > moment in time as the PEBS record, so reflect the correct branch
> >
On Sat, Nov 10, 2018 at 8:07 PM Andi Kleen wrote:
>
> On Sat, Nov 10, 2018 at 04:42:48PM -0500, Travis Downs wrote:
> > I guess this problem doesn't occur for LBR unwinding since the LBR
> > records are captured at the same
> > moment in time as the PEBS record, so reflect the correct branch
> >
On Sat, Nov 10, 2018 at 04:42:48PM -0500, Travis Downs wrote:
> I guess this problem doesn't occur for LBR unwinding since the LBR
> records are captured at the same
> moment in time as the PEBS record, so reflect the correct branch
> sequence.
Actually it happens with LBRs too, but it always
On Sat, Nov 10, 2018 at 04:42:48PM -0500, Travis Downs wrote:
> I guess this problem doesn't occur for LBR unwinding since the LBR
> records are captured at the same
> moment in time as the PEBS record, so reflect the correct branch
> sequence.
Actually it happens with LBRs too, but it always
On Mon, Nov 5, 2018 at 7:11 PM Andi Kleen wrote:
> Milian is right.
>
> There is a execution window from PEBS capturing registers to actually
> triggering
> the PMU, and if there is stack manipulation in that window
> the PEBS state might be out of sync with the real stack.
This explains some
On Mon, Nov 5, 2018 at 7:11 PM Andi Kleen wrote:
> Milian is right.
>
> There is a execution window from PEBS capturing registers to actually
> triggering
> the PMU, and if there is stack manipulation in that window
> the PEBS state might be out of sync with the real stack.
This explains some
> Can we change this, such that perf_event_output also takes a second set of
> registers (iregs) that get sampled for PERF_SAMPLE_REGS_INTR? I'm very new to
> real kernel development, what kind of ABI/API stability guarantees exist for
> something like "perf_event_output"?
Yes you can change
> Can we change this, such that perf_event_output also takes a second set of
> registers (iregs) that get sampled for PERF_SAMPLE_REGS_INTR? I'm very new to
> real kernel development, what kind of ABI/API stability guarantees exist for
> something like "perf_event_output"?
Yes you can change
> - Independently, when I add a custom printk manually in `arch/x86/events/
> intel/ds.c` at the end of `setup_pebs_sample_data`, then I'm never seeing any
> differences between SP in iregs/pebs/regs. Shouldn't it also be recorded via
> PEBS? Or is it just chance that I'm never seeing any
> - Independently, when I add a custom printk manually in `arch/x86/events/
> intel/ds.c` at the end of `setup_pebs_sample_data`, then I'm never seeing any
> differences between SP in iregs/pebs/regs. Shouldn't it also be recorded via
> PEBS? Or is it just chance that I'm never seeing any
On Mittwoch, 7. November 2018 23:41:31 CET Milian Wolff wrote:
> On Dienstag, 6. November 2018 21:24:11 CET Andi Kleen wrote:
> > > Where would I look for the source to change here? So far, I only
> > > concentrated on the userspace side of perf in tools/perf.
> >
> > Kind of similar to
> >
> >
On Mittwoch, 7. November 2018 23:41:31 CET Milian Wolff wrote:
> On Dienstag, 6. November 2018 21:24:11 CET Andi Kleen wrote:
> > > Where would I look for the source to change here? So far, I only
> > > concentrated on the userspace side of perf in tools/perf.
> >
> > Kind of similar to
> >
> >
On Dienstag, 6. November 2018 21:24:11 CET Andi Kleen wrote:
> > Where would I look for the source to change here? So far, I only
> > concentrated on the userspace side of perf in tools/perf.
>
> Kind of similar to
>
> a405bad5ad20 perf/x86: Add Haswell specific transaction flag reporting
>
On Dienstag, 6. November 2018 21:24:11 CET Andi Kleen wrote:
> > Where would I look for the source to change here? So far, I only
> > concentrated on the userspace side of perf in tools/perf.
>
> Kind of similar to
>
> a405bad5ad20 perf/x86: Add Haswell specific transaction flag reporting
>
> Where would I look for the source to change here? So far, I only concentrated
> on the userspace side of perf in tools/perf.
Kind of similar to
a405bad5ad20 perf/x86: Add Haswell specific transaction flag reporting
fdfbbd07e91f perf: Add generic transaction flags
Report the original (not
> Where would I look for the source to change here? So far, I only concentrated
> on the userspace side of perf in tools/perf.
Kind of similar to
a405bad5ad20 perf/x86: Add Haswell specific transaction flag reporting
fdfbbd07e91f perf: Add generic transaction flags
Report the original (not
On Dienstag, 6. November 2018 09:39:57 CET Jiri Olsa wrote:
> On Mon, Nov 05, 2018 at 04:10:37PM -0800, Andi Kleen wrote:
> > > > > - PMU triggers interrupt and PEBS stores RIP etc.
> > > > > - code continous to execute, possibly changing the stack
> > > >
> > > > I dont think the code continues
On Dienstag, 6. November 2018 09:39:57 CET Jiri Olsa wrote:
> On Mon, Nov 05, 2018 at 04:10:37PM -0800, Andi Kleen wrote:
> > > > > - PMU triggers interrupt and PEBS stores RIP etc.
> > > > > - code continous to execute, possibly changing the stack
> > > >
> > > > I dont think the code continues
> hum, is this about having 'large pebs' or there's this window
> if there's also only single pebs record allowed? which should
> be case for dwarf unwind
With large PEBS today there is never any stack unwind because
stack unwinding can be only done from a PMI.
The window happens even with
> hum, is this about having 'large pebs' or there's this window
> if there's also only single pebs record allowed? which should
> be case for dwarf unwind
With large PEBS today there is never any stack unwind because
stack unwinding can be only done from a PMI.
The window happens even with
On Mon, Nov 05, 2018 at 04:10:37PM -0800, Andi Kleen wrote:
> > > > - PMU triggers interrupt and PEBS stores RIP etc.
> > > > - code continous to execute, possibly changing the stack
> > >
> > > I dont think the code continues to execute.. the stack is ok
> >
> > Are you sure about this? I mean,
On Mon, Nov 05, 2018 at 04:10:37PM -0800, Andi Kleen wrote:
> > > > - PMU triggers interrupt and PEBS stores RIP etc.
> > > > - code continous to execute, possibly changing the stack
> > >
> > > I dont think the code continues to execute.. the stack is ok
> >
> > Are you sure about this? I mean,
> > > - PMU triggers interrupt and PEBS stores RIP etc.
> > > - code continous to execute, possibly changing the stack
> >
> > I dont think the code continues to execute.. the stack is ok
>
> Are you sure about this? I mean, isn't that the whole reason why we need
> PEBS?
> Generally, if you
> > > - PMU triggers interrupt and PEBS stores RIP etc.
> > > - code continous to execute, possibly changing the stack
> >
> > I dont think the code continues to execute.. the stack is ok
>
> Are you sure about this? I mean, isn't that the whole reason why we need
> PEBS?
> Generally, if you
On Montag, 5. November 2018 21:51:19 CET Jiri Olsa wrote:
> On Fri, Nov 02, 2018 at 06:56:50PM +0100, Milian Wolff wrote:
>
> SNIP
>
> > > > Note how precise levels 0 and 1 do not produce any samples where
> > > > unwinding
> > > > fails. But precise level 2 produces some, and precise level 3
>
On Montag, 5. November 2018 21:51:19 CET Jiri Olsa wrote:
> On Fri, Nov 02, 2018 at 06:56:50PM +0100, Milian Wolff wrote:
>
> SNIP
>
> > > > Note how precise levels 0 and 1 do not produce any samples where
> > > > unwinding
> > > > fails. But precise level 2 produces some, and precise level 3
>
On Fri, Nov 02, 2018 at 06:56:50PM +0100, Milian Wolff wrote:
SNIP
> > >
> > > Note how precise levels 0 and 1 do not produce any samples where unwinding
> > > fails. But precise level 2 produces some, and precise level 3 increases
> > > the
> > > amount (by ca. ~2x).
> > >
> > > I can
On Fri, Nov 02, 2018 at 06:56:50PM +0100, Milian Wolff wrote:
SNIP
> > >
> > > Note how precise levels 0 and 1 do not produce any samples where unwinding
> > > fails. But precise level 2 produces some, and precise level 3 increases
> > > the
> > > amount (by ca. ~2x).
> > >
> > > I can
On Freitag, 2. November 2018 12:26:35 CET Jiri Olsa wrote:
> On Thu, Nov 01, 2018 at 11:08:18PM +0100, Milian Wolff wrote:
> > On Dienstag, 30. Oktober 2018 23:34:35 CET Milian Wolff wrote:
> > > On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > > > > Can someone at least confirm
On Freitag, 2. November 2018 12:26:35 CET Jiri Olsa wrote:
> On Thu, Nov 01, 2018 at 11:08:18PM +0100, Milian Wolff wrote:
> > On Dienstag, 30. Oktober 2018 23:34:35 CET Milian Wolff wrote:
> > > On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > > > > Can someone at least confirm
On Thu, Nov 01, 2018 at 11:08:18PM +0100, Milian Wolff wrote:
> On Dienstag, 30. Oktober 2018 23:34:35 CET Milian Wolff wrote:
> > On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > > > Can someone at least confirm whether unwinding from a function prologue
> > > > via
> > > >
On Thu, Nov 01, 2018 at 11:08:18PM +0100, Milian Wolff wrote:
> On Dienstag, 30. Oktober 2018 23:34:35 CET Milian Wolff wrote:
> > On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > > > Can someone at least confirm whether unwinding from a function prologue
> > > > via
> > > >
On Dienstag, 30. Oktober 2018 23:34:35 CET Milian Wolff wrote:
> On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > > Can someone at least confirm whether unwinding from a function prologue
> > > via
> > > .eh_frame (but without .debug_frame) should actually be possible?
> >
> > Yes
On Dienstag, 30. Oktober 2018 23:34:35 CET Milian Wolff wrote:
> On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > > Can someone at least confirm whether unwinding from a function prologue
> > > via
> > > .eh_frame (but without .debug_frame) should actually be possible?
> >
> > Yes
On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > Can someone at least confirm whether unwinding from a function prologue
> > via
> > .eh_frame (but without .debug_frame) should actually be possible?
>
> Yes it should be possible. Asynchronous unwind tables should work
> from any
On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > Can someone at least confirm whether unwinding from a function prologue
> > via
> > .eh_frame (but without .debug_frame) should actually be possible?
>
> Yes it should be possible. Asynchronous unwind tables should work
> from any
>
> Can someone at least confirm whether unwinding from a function prologue via
> .eh_frame (but without .debug_frame) should actually be possible?
Yes it should be possible. Asynchronous unwind tables should work
from any instruction.
-Andi
>
> Can someone at least confirm whether unwinding from a function prologue via
> .eh_frame (but without .debug_frame) should actually be possible?
Yes it should be possible. Asynchronous unwind tables should work
from any instruction.
-Andi
On Dienstag, 23. Oktober 2018 06:03:56 CEST Andi Kleen wrote:
> > So what if my libm wasn't compiled with -fasynchronous-unwind-tables? We
>
> It's default (64bit since always and 32bit now too) Unless someone disabled
> it.
Excellent, good to know. Since [1] doesn't explicitly disable it, I
On Dienstag, 23. Oktober 2018 06:03:56 CEST Andi Kleen wrote:
> > So what if my libm wasn't compiled with -fasynchronous-unwind-tables? We
>
> It's default (64bit since always and 32bit now too) Unless someone disabled
> it.
Excellent, good to know. Since [1] doesn't explicitly disable it, I
> So what if my libm wasn't compiled with -fasynchronous-unwind-tables? We
It's default (64bit since always and 32bit now too) Unless someone disabled it.
However libm might be partially written in assembler and hand written assembler
often has problems with unwind tables because the programmer
> So what if my libm wasn't compiled with -fasynchronous-unwind-tables? We
It's default (64bit since always and 32bit now too) Unless someone disabled it.
However libm might be partially written in assembler and hand written assembler
often has problems with unwind tables because the programmer
On Montag, 22. Oktober 2018 15:58:17 CEST Andi Kleen wrote:
> Milian Wolff writes:
> > After more digging, it turns out that I've apparently chased a red
> > herring.
> > I'm running archlinux which isn't shipping debug symbols for libm.
>
> 64bit executables normally have unwind information
On Montag, 22. Oktober 2018 15:58:17 CEST Andi Kleen wrote:
> Milian Wolff writes:
> > After more digging, it turns out that I've apparently chased a red
> > herring.
> > I'm running archlinux which isn't shipping debug symbols for libm.
>
> 64bit executables normally have unwind information
Milian Wolff writes:
>
> After more digging, it turns out that I've apparently chased a red herring.
> I'm running archlinux which isn't shipping debug symbols for libm.
64bit executables normally have unwind information even when stripped.
Unless someone forcefully stripped those too.
You can
Milian Wolff writes:
>
> After more digging, it turns out that I've apparently chased a red herring.
> I'm running archlinux which isn't shipping debug symbols for libm.
64bit executables normally have unwind information even when stripped.
Unless someone forcefully stripped those too.
You can
On Montag, 22. Oktober 2018 12:35:39 CEST Milian Wolff wrote:
> On Sonntag, 21. Oktober 2018 00:39:51 CEST Milian Wolff wrote:
> > Hey all,
> >
> > I'm on the quest to figure out why perf regularly fails to unwind (some)
> > samples. I am seeing very strange behavior, where an apparently wrong
>
On Montag, 22. Oktober 2018 12:35:39 CEST Milian Wolff wrote:
> On Sonntag, 21. Oktober 2018 00:39:51 CEST Milian Wolff wrote:
> > Hey all,
> >
> > I'm on the quest to figure out why perf regularly fails to unwind (some)
> > samples. I am seeing very strange behavior, where an apparently wrong
>
On Sonntag, 21. Oktober 2018 00:39:51 CEST Milian Wolff wrote:
> Hey all,
>
> I'm on the quest to figure out why perf regularly fails to unwind (some)
> samples. I am seeing very strange behavior, where an apparently wrong stack
> pointer value is read from the register - see below for more
On Sonntag, 21. Oktober 2018 00:39:51 CEST Milian Wolff wrote:
> Hey all,
>
> I'm on the quest to figure out why perf regularly fails to unwind (some)
> samples. I am seeing very strange behavior, where an apparently wrong stack
> pointer value is read from the register - see below for more
On Sonntag, 21. Oktober 2018 00:39:51 CEST Milian Wolff wrote:
> Hey all,
>
> I'm on the quest to figure out why perf regularly fails to unwind (some)
> samples. I am seeing very strange behavior, where an apparently wrong stack
> pointer value is read from the register - see below for more
On Sonntag, 21. Oktober 2018 00:39:51 CEST Milian Wolff wrote:
> Hey all,
>
> I'm on the quest to figure out why perf regularly fails to unwind (some)
> samples. I am seeing very strange behavior, where an apparently wrong stack
> pointer value is read from the register - see below for more
Hey all,
I'm on the quest to figure out why perf regularly fails to unwind (some)
samples. I am seeing very strange behavior, where an apparently wrong stack
pointer value is read from the register - see below for more information and
the end of this (long) mail for my open questions. Any help
Hey all,
I'm on the quest to figure out why perf regularly fails to unwind (some)
samples. I am seeing very strange behavior, where an apparently wrong stack
pointer value is read from the register - see below for more information and
the end of this (long) mail for my open questions. Any help
66 matches
Mail list logo
