Hi, Another thing that occurred to me while using PERF_SAMPLE_GROUP is about that unique ID which you get out of read() with PERF_FORMAT_ID.
That number if generated by the kernel and it is a globally incrementing 64-bit counter. An application may not get subsequent numbers even though it is issuing perf_open_counter() in sequence. Another applications may cause the number to change. I believe this is not very convenient because imagine in your signal handler you parse the GROUP and you want to relate id to the event. You need to have a lookup table. I believe it would be more convenient if the tool could pass a 64-bit number itself when the event is created. It would get it back as part of PERF_SAMPLE_GROUP. The id could then be more related to the tool's data structure, no need for a lookup table, overall more efficient. If I recall, this is what epoll() can do and this is very convenient. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
