On (06/01/17 15:25), Peter Zijlstra wrote:
[..]
> On Thu, Jun 01, 2017 at 07:47:05AM -0500, Josh Poimboeuf wrote:
>
> > > It doesn't appear to be possible to get anywhere near a frame-pointer
> > > unwinder due to having to do this log(n) lookup for every single
> > > frame.
> >
> > Hm, is there
On Thu, Jun 01, 2017 at 04:08:25PM +0200, Jiri Slaby wrote:
> Ccing Mel who did proper measurements and can hopefully comment on his
> results.
>
> On 06/01/2017, 03:50 PM, Ingo Molnar wrote:
> > That's not what I meant! The speedup comes from (hopefully) being able to
> > disable
> > CONFIG_FRA
On 06/01/2017, 03:58 PM, Jiri Slaby wrote:
> On 06/01/2017, 03:50 PM, Ingo Molnar wrote:
>> That's not what I meant! The speedup comes from (hopefully) being able to
>> disable
>> CONFIG_FRAME_POINTER, which:
>
> BTW when you are mentioning this -- my measurements were with FP disabled.
>
> Is
Ccing Mel who did proper measurements and can hopefully comment on his
results.
On 06/01/2017, 03:50 PM, Ingo Molnar wrote:
> That's not what I meant! The speedup comes from (hopefully) being able to
> disable
> CONFIG_FRAME_POINTER, which:
>
> - creates simpler/faster function prologues and e
On Thu, Jun 01, 2017 at 03:50:05PM +0200, Ingo Molnar wrote:
> * Josh Poimboeuf wrote:
> > On Thu, Jun 01, 2017 at 08:08:24AM +0200, Ingo Molnar wrote:
> > > Being able to generate more optimal code in the hottest code paths of the
> > > kernel
> > > is the _real_, primary upstream kernel benefi
On 06/01/2017, 03:50 PM, Ingo Molnar wrote:
> That's not what I meant! The speedup comes from (hopefully) being able to
> disable
> CONFIG_FRAME_POINTER, which:
BTW when you are mentioning this -- my measurements were with FP disabled.
Is there any reasonably simple-to-use benchmark I could run
On Thu, Jun 1, 2017 at 5:47 AM, Josh Poimboeuf wrote:
> On Thu, Jun 01, 2017 at 02:17:21PM +0200, Peter Zijlstra wrote:
>> On Thu, Jun 01, 2017 at 06:58:20AM -0500, Josh Poimboeuf wrote:
>> > > Being able to generate more optimal code in the hottest code paths of
>> > > the kernel
>> > > is the _
* Josh Poimboeuf wrote:
> On Thu, Jun 01, 2017 at 08:08:24AM +0200, Ingo Molnar wrote:
> >
> > * Josh Poimboeuf wrote:
> >
> > > Here's the contents of the undwarf.txt file which explains the 'why' in
> > > more detail:
> >
> > Ok, so the code quality looks pretty convincing to me - the new
On Thu, Jun 01, 2017 at 07:47:05AM -0500, Josh Poimboeuf wrote:
> > It doesn't appear to be possible to get anywhere near a frame-pointer
> > unwinder due to having to do this log(n) lookup for every single
> > frame.
>
> Hm, is there something faster, yet not substantially bigger? Hash?
> Trie?
On 06/01/2017, 02:52 PM, Josh Poimboeuf wrote:
>> This is ~ 20 times faster than my DWARF unwinder by a quick measurement
>> (2 calls to save_stack_trace via single vfs_write).
>
> Wow!
BTW the most time spent when unwinding DWARF was in those routines
decrypting uleb/sleb128 into u/longs.
t
On Thu, Jun 01, 2017 at 02:33:20PM +0200, Jiri Slaby wrote:
> On 06/01/2017, 02:17 PM, Peter Zijlstra wrote:
> > On Thu, Jun 01, 2017 at 06:58:20AM -0500, Josh Poimboeuf wrote:
> >>> Being able to generate more optimal code in the hottest code paths of the
> >>> kernel
> >>> is the _real_, primar
On Thu, Jun 01, 2017 at 02:17:21PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 01, 2017 at 06:58:20AM -0500, Josh Poimboeuf wrote:
> > > Being able to generate more optimal code in the hottest code paths of the
> > > kernel
> > > is the _real_, primary upstream kernel benefit of a different debugi
On 06/01/2017, 02:17 PM, Peter Zijlstra wrote:
> On Thu, Jun 01, 2017 at 06:58:20AM -0500, Josh Poimboeuf wrote:
>>> Being able to generate more optimal code in the hottest code paths of the
>>> kernel
>>> is the _real_, primary upstream kernel benefit of a different debuginfo
>>> method -
>>>
On Thu, Jun 01, 2017 at 06:58:20AM -0500, Josh Poimboeuf wrote:
> > Being able to generate more optimal code in the hottest code paths of the
> > kernel
> > is the _real_, primary upstream kernel benefit of a different debuginfo
> > method -
> > which has to be weighed against the pain of intro
On Thu, Jun 01, 2017 at 08:08:24AM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > Here's the contents of the undwarf.txt file which explains the 'why' in
> > more detail:
>
> Ok, so the code quality looks pretty convincing to me - the new core
> 'undwarf'
> unwinder code is a _lo
* Josh Poimboeuf wrote:
> Here's the contents of the undwarf.txt file which explains the 'why' in
> more detail:
Ok, so the code quality looks pretty convincing to me - the new core 'undwarf'
unwinder code is a _lot_ more readable than any of the Dwarf based attempts
before.
That we control
16 matches
Mail list logo
