[SERVER-41186] Benchmark backtrace/unwind techniques Created: 16/May/19  Updated: 29/May/19  Resolved: 29/May/19

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Benjamin Caimano (Inactive) Assignee: Benjamin Caimano (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive backtrace-benchmarks.zip    
Sprint: Service Arch 2019-06-03
Participants:

 Description   

It turns out there are 3 semi-reasonable ways to extract a stack on a posix system:

  • Assembly extracting sp and winding up
  • Using libunwind
  • Using glibc backtrace

We need to benchmark these



 Comments   
Comment by Benjamin Caimano (Inactive) [ 29/May/19 ]

As an additional note, I tested this with an associated condvar wait after each run. It looks like it was 7us without trace to 12us with. That's quick enough that it won't matter at all with waits of any duration, but it will be noticeable if we're doing trivial waits most of time.

Comment by Benjamin Caimano (Inactive) [ 29/May/19 ]

Uploading my mildly hacky benchmarking work here: backtrace-benchmarks.zip .

My general conclusion is that libunwind backtrace() is almost as fast as working with raw stack unwinding. Posix backtrace() is fairly slower at about 2x. Perhaps unsurprisingly, the libunwind generalized context unwinder is slower than the backtrace function, I suspect it is grabbing and storing a bunch of extra details behind the scenes.

The big take away is that it's easily possible for us to take a backtrace ala ~20us, but the call dladdr() takes at least 4x as long. We might want to call dl_iterate_phdr() at start up or scan our elf segments loaded in some other fashion. That way we can translate to offsets from segment when it matters for symbolizing.

Comment by Benjamin Caimano (Inactive) [ 29/May/19 ]

This is an investigation ticket, but it still irritates me that it's not scheduled

Generated at Thu Feb 08 04:57:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.