Thinker, thanks! This sounds really cool. As far as I know, we can enable profiling to track some status(or maybe for performance issues). Will this be included in the profiling? And, will we have any Wiki page for this? :)
Thanks. Kevin Hu On Aug 24, 2013, at 6:15 PM, Thinker K.F. Li wrote: > 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 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
