[ Bcc'ing auto-tools, in case a-team peoples missed this ]
Hi Dave,
This sounds really cool. I suspect that posting this on dev.platform
might yield more comments... personally I only have some minor comments
which are hopefully still useful:
On 04/07/2014 01:34 PM, Dave Huseby wrote:
Here is what I'm thinking in rough priority order:
1. Unify event signaling for all sources of "interesting" events.
Right now we have a bunch of "interesting" perf-related events (e.g.
checkerboarding, memory pressures, zRAM caching, power consumption
spikes, slow event handling, etc) that are reported in different ways.
For instance, Ben Kelly showed us how to spot memory pressure events in
the log output. We learned that the graphics pipeline knows when
checkerboarding occurs and could report that. We saw how the powertool
can see when power consumption spikes and could report it. zRAM caching
events reported from B2G. RIL, WiFi, GPS, etc all reported from B2G in
the logs.
So I know there was an effort to add performance counters to marionette
last year, which sounds similar to what you are talking about. I think
we eventually abandoned that effort, for what reason I don't know.
CC'ing mdas, who IIRC was working on it -- hopefully she can clarify.
The first step I think we should take is figuring out a way to report
interesting events via a unified mechanism. For events generated on the
device, I think the Profiler::addMarker is the good way to go. Not only
would it be a single, central reporting mechanism available from both
C++ and JS, it would also get those events into the profiling capture
buffer. The profiling capture mechanism has a small circular buffer for
storing stack traces and markers. There's no reason we couldn't have a
thread transmitting event markers back to the host over a socket in
realtime.
For events generated off of the device (e.g. powertool events,
eideticker events, orangutan input driver events), they could also be
reported over a socket to the event consumer.
So for orangutan, the thing that counts the most is when we dispatch the
event to the kernel subsystem to the device, not when we trigger the
program off the device. Would it be possible for external programs like
this to report something to gecko, then gecko would report them over the
socket? I don't want to bikeshed the implementation too much, just
curious about your thoughts here...
2. Build a single consumer of the event stream.
Once we get event reporting over a socket, the next step is to build a
centralized consumer of the events. NodeJS is probably a good choice
for this tool. It should probably function as a daemon on the host
machine and be capable of detecting devices and executing adb commands
to set up the port forwarding automagically. The event consumer will
listen on a single port--like a web server--and accept multiple incoming
connections from event sources.
So the way android port-forwarding works, it is currently possible for
the host to connect to a tcp socket on the device easily over usb (this
is how we do marionette), but not the reverse. So I suspect it would be
easier for gecko to emit events over a socket, then have some process on
the host hook into that.
3. Build a configurable dispatch mechanism for the event consumer.
The last piece involves building a configurable dispatch mechanism for
hooking up actions to certain events. The first--and maybe the
only--action we will want is to gather the profiling data for the last N
seconds whenever we see an interesting event.
For instance, when I'm optimizing idle power draw, a power spike event
from the powertool should trigger dumping the profiling data for the
last N seconds. I'll also want the profiling data when I see a
transient memory spikes and checkerboarding events, and...
Now that I think about it, grabbing the profiler data in response to a
marker added from JS would be tremendously helpful for debugging JS
event ordering and dispatching issues (i.e. the gaia window manager).
Proposal:
To keep this simple enough that it could be implemented quickly, I
propose a very simple event transmission mechanism. The data on the
socket will flow in only one direction--from the event source to the
consumer. Events will contain JSON encoded data: a timestamp with
sub-ms resolution, a subject string, and a body string. The subject is
what triggers an action, the body is used for any optional/extended
data. We'll use TCP.
So the ateam has been working on adding something called "structured
logging" to all our frameworks, which uses a json protocol much like
what you're describing. It would be great if you could use something
similar here, so all the python tools we're creating for reading/parsing
structured logs could be reused here. I believe we also have some
existing javascript helper methods in the tree for creating these types
of json messages. Here's a description of the format we're using:
http://mozbase.readthedocs.org/en/latest/mozlog_structured.html#data-format
Will
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
