For the overhead, I am not really sure, but, by my previous experiences, it is not obviously. In additionally, by using TSC provided by CPU, the overhead is comprised by register reading and some memory reading and writing. It is a fixed overhead for every posted runnable. Comparing to the runnable itself, it should be a minor part.
I think it should be enabled by a flag, at least at beginning. The data would be in text format that can be hanled by grep, awk, sort, ... etc. For long term, we need to visualize the data. But, for now, the infrastructures for tracing is more important than visualizing. Maybe some others who is better on visualizing will do it. It is bug 908995. Ben Kelly <[email protected]> writes: > On 08/23/2013 11:29 AM, Thinker K.F. Li wrote: >> We are working on a tool to help people to correlate runnables spread >> over threads and processes (b2g & content process). The basic idea is >> to give every runnable an unique ID, all runnables created by a runnable >> share the same unique ID. Only the runnables created by events from >> kernel/platform; e.g. input event, timer, network, sensors, ..., would >> be assigned a new unique ID. So we can correlate all runnables >> according unique IDs to understand the tracks of events. >> >> The runnables created by events are origins. For example an input event >> post a runnable on the main thread, that runnable is the origin of the >> event. The origin gets a new unique ID. The origin may create a series >> of more runanbles, they all share the same ID. By recording timestamp >> for equeuing, dequeuing, and completion of runnables, and the unqiue >> IDs, we can study how b2g spend the time and latency between threads for >> events. >> >> The unique IDs would be passed over IPC, so we can trace runnables >> passed among processes. Some more information can be attached with the >> unique IDs. But we would like to start by simple, so I don't mention >> details here. > > This sounds like a great tool! > > I'm curious if you have any idea about how much overhead this will add? > It sounds like it won't be bad. Are you planning to make it always on > or require a compile flag? > > Also, how do you see us getting the data out? I assume the next problem > to solve will be visualizing the data usefully. > > Finally, do you have a bug number for tracking this work? I'd like to > follow along on CC. > > Thanks! > > Ben -- Sinker -- 天教懶漫帶疏狂 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
