On Wed, Apr 17, 2019 at 10:44:33PM +0800, Kairui Song wrote:
> Despite it's hacky, it seems not necessary to dump every register. And
> is there a straight way to get caller's regs in the trace point? It
> seems more trouble some. Or if we just use the regs inside the
> tracepoint, but it would nee
On Wed, Apr 17, 2019 at 09:07:35AM +0200, Peter Zijlstra wrote:
> On Tue, Apr 16, 2019 at 03:15:59PM -0500, Josh Poimboeuf wrote:
> > If you do the regs->eflags thing to mark the regs as fake in
> > (perf_arch_fetch_caller_regs()), then I don't think skip_sp would be
> > needed, because regs->sp co
On Wed, Apr 17, 2019 at 4:16 AM Josh Poimboeuf wrote:
>
> On Wed, Apr 17, 2019 at 01:39:19AM +0800, Kairui Song wrote:
> > On Tue, Apr 16, 2019 at 7:30 PM Kairui Song wrote:
> > >
> > > On Tue, Apr 16, 2019 at 12:59 AM Josh Poimboeuf
> > > wrote:
> > > >
> > > > On Mon, Apr 15, 2019 at 05:36:22
On Wed, Apr 17, 2019 at 1:45 AM Peter Zijlstra wrote:
>
> On Wed, Apr 17, 2019 at 01:39:19AM +0800, Kairui Song wrote:
> > And I also think the "fake"/"real" reg is fragile, could we abuse
> > another eflag (just like PERF_EFLAGS_EXACT) to indicate the regs are
> > partially dumped fake registers?
On Tue, Apr 16, 2019 at 03:15:59PM -0500, Josh Poimboeuf wrote:
> If you do the regs->eflags thing to mark the regs as fake in
> (perf_arch_fetch_caller_regs()), then I don't think skip_sp would be
> needed, because regs->sp could probably mark the skip point.
>
> Instead I was actually hoping we
On Wed, Apr 17, 2019 at 01:39:19AM +0800, Kairui Song wrote:
> On Tue, Apr 16, 2019 at 7:30 PM Kairui Song wrote:
> >
> > On Tue, Apr 16, 2019 at 12:59 AM Josh Poimboeuf wrote:
> > >
> > > On Mon, Apr 15, 2019 at 05:36:22PM +0200, Peter Zijlstra wrote:
> > > >
> > > > I'll mostly defer to Josh on
On Wed, Apr 17, 2019 at 01:39:19AM +0800, Kairui Song wrote:
> And I also think the "fake"/"real" reg is fragile, could we abuse
> another eflag (just like PERF_EFLAGS_EXACT) to indicate the regs are
> partially dumped fake registers?
Sure, the SDM seems to suggest bits 1,3,5,15 are 'available'.
On Tue, Apr 16, 2019 at 7:30 PM Kairui Song wrote:
>
> On Tue, Apr 16, 2019 at 12:59 AM Josh Poimboeuf wrote:
> >
> > On Mon, Apr 15, 2019 at 05:36:22PM +0200, Peter Zijlstra wrote:
> > >
> > > I'll mostly defer to Josh on unwinding, but a few comments below.
> > >
> > > On Tue, Apr 09, 2019 at 1
On Tue, Apr 16, 2019 at 07:30:07PM +0800, Kairui Song wrote:
> On Tue, Apr 16, 2019 at 12:59 AM Josh Poimboeuf wrote:
> >
> > On Mon, Apr 15, 2019 at 05:36:22PM +0200, Peter Zijlstra wrote:
> > >
> > > I'll mostly defer to Josh on unwinding, but a few comments below.
> > >
> > > On Tue, Apr 09, 20
On Tue, Apr 16, 2019 at 12:59 AM Josh Poimboeuf wrote:
>
> On Mon, Apr 15, 2019 at 05:36:22PM +0200, Peter Zijlstra wrote:
> >
> > I'll mostly defer to Josh on unwinding, but a few comments below.
> >
> > On Tue, Apr 09, 2019 at 12:59:42AM +0800, Kairui Song wrote:
> > > diff --git a/arch/x86/even
On Mon, Apr 15, 2019 at 05:36:22PM +0200, Peter Zijlstra wrote:
>
> I'll mostly defer to Josh on unwinding, but a few comments below.
>
> On Tue, Apr 09, 2019 at 12:59:42AM +0800, Kairui Song wrote:
> > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> > index e2b1447192a8..6075a4f94
I'll mostly defer to Josh on unwinding, but a few comments below.
On Tue, Apr 09, 2019 at 12:59:42AM +0800, Kairui Song wrote:
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index e2b1447192a8..6075a4f94376 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
>
On Tue, Apr 09, 2019 at 12:59:42AM +0800, Kairui Song wrote:
> Currently perf callchain is not working properly with ORC unwinder,
> and sampling event from trace point. We'll get useless in kernel
> callchain like this:
>
> perf 6429 [000]22.498450: kmem:mm_page_alloc: page=0x176
Currently perf callchain is not working properly with ORC unwinder,
and sampling event from trace point. We'll get useless in kernel
callchain like this:
perf 6429 [000]22.498450: kmem:mm_page_alloc: page=0x176a17
pfn=1534487 order=0 migratetype=0 gfp_flags=GFP_KERNEL
fff
14 matches
Mail list logo
