So let's have a separate bug for turning on stack walking. Bug 916106 is a source of concern. +++ This bug was initially created as a clone of Bug #919078 +++ Starting the profiler asynchronously will be more useful if more features are enabled; in particular, "js" and "stackwalk" (or "leaf" on platforms where stack walking isn't available) are ones that I predict most users of the profiler will expect, and which the existing profiler-start-on-startup mechanism enables.

Bug 916106 has landed. Is there anything else that needs to happen to turn on stack walking by default on ARM B2G?

What's the difference in CPU usage by having this on by default when idle?

On keon, with the CPU set to maximum speed (1008 MHz) instead of being dynamically scaled: Not profiling: 0.4% Profiling with js+leaf: 6.7% Profiling with js+stackwalk: 7.0% That's the main thread of the main b2g process, sitting at the home screen, with the usual screen blanking on inactivity disabled.

Forgot to mention: measured by adding the "utime" and "stime" fields (14 and 15) from /proc/N/stat, and measured over 300 seconds.

That's impressive. Alright lets turn it on!

Comment on attachment 820502 [details] [diff] [review] bug926610-stackwalk-on-async-hg0.diff We're going to roll this into bug 925111, since that patch completely overwrites the code that would be changed here.

The profiler features for async profiler starts seem to be read from a "profiler.options" file and are no longer hardcoded. But I think this method of starting the profiler from a signal handler was only ever used on B2G anyway and can probably removed.