877522 - Allow Linux perf_event sampling of context switches to get call stacks on B2G

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This was looked at in bug 847592 — see bug 847592 comment 49 and the next few — but it needs its own bug.  To summarize: We'll sometimes want to know what threads are doing when they're not on the CPU — if they're blocked (and, if so, on what) or if they're runnable but not running due to scheduling decisions.  The perf_event framework has an event type for probing context switches, which would give us this information, but it doesn't gather call stacks on ARM.  It looks as if at least part of what's missing is perf_arch_fetch_caller_regs[1], whose implementations on other platforms are relatively simple.  That retrieves the necessary kernel registers, so there may be something else needed to get the user stack as well.

[1] http://lxr.free-electrons.com/ident?i=perf_arch_fetch_caller_regs

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Linux kernel patch (against 3.10.0-rc5+) to add perf_arch_fetch_caller_regs on ARM

Here's a patch against Linux master.  Note that it hasn't been run past upstream yet, and it may not apply cleanly to other versions.

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Linux kernel patch (against 3.0.8-GP+) to add perf_arch_fetch_caller_regs on ARM

This one is for applying to the geeksphone keon kernel.

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I got a proof-of-concept working, Wednesday morning during the Oslo work week: https://people.mozilla.org/~bgirard/cleopatra/#report=619e178f5e8e20e78f9b07ab2dd4e5e0b7176345

Judging by the relatively large number of non-unwound samples there are probably some bugs, but it works.

The question is: how does this compare to the Gecko profiler, especially given that it's gaining the ability to sample multiple threads in different processes and combine them into one profile (which was arguably perf's big advantage), and should soon be able to trace past jitcode (which at this point perf seems unlikely to ever be able to do, at least not without even more kernel changes and special-case hacks)?

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I still think being able to tell why a thread is blocked (just switched out, stuck on IO, waiting for a lock) is extremely valuable. If we can get that information with the Gecko profiler then I'm happy.

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This is probably not happening in any form; I think the Gecko profiler can get roughly equivalent information by now; and it's possible that the upstream Linux kernel already took care of this.