lkml.org 
[lkml]   [2017]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)
    On Thu, Jul 13, 2017 at 10:50:15AM +0200, Peter Zijlstra wrote:
    > On Thu, Jul 13, 2017 at 09:12:53AM +0200, Peter Zijlstra wrote:
    > > On Wed, Jul 12, 2017 at 05:32:25PM -0500, Josh Poimboeuf wrote:
    > > > If you want perf to be able to use ORC instead of DWARF for user space
    > > > binaries, that's not currently possible, though I don't see any
    > > > technical blockers for doing so. Perf would need to be taught to read
    > > > ORC data.
    > >
    > > So the problem with userspace stuff is that the unwind data isn't
    > > readily available from NMI context.
    > >
    > > So the kernel unwinder will trigger a fault and abort.
    > >
    > > The very best we can hope for is using the EH [*] stuff that all
    > > binaries actually have _and_ map. The only problem is that most programs
    > > don't actually use the EH stuff much so while its mapped, its not
    > > actually paged in, so we're still stuck.
    >
    > One gloriously ugly hack would be to delay the userspace unwind to
    > return-to-userspace, at which point we have a schedulable context and
    > can take faults.
    >
    > Of course, then you have to somehow identify this later unwind sample
    > with all relevant prior samples and stitch the whole thing back
    > together, but that should be doable.
    >
    > In fact, it would be at all hard to do, just queue a task_work from the

    +not

    > NMI and have that do the EH based unwind.

    \
     
     \ /
      Last update: 2017-07-13 10:51    [W:3.873 / U:0.340 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site