| Summary: | Need remote profiler (sysprof or eclipse?) | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Mihail Stanciu <stanciux.mihail> |
| Component: | devtools / tool chain | Assignee: | Unassigned <unassigned> |
| Status: | CLOSED WONTFIX | QA Contact: | Apoorv <apoorv.sangal> |
| Severity: | normal | ||
| Priority: | Medium | CC: | alexandru.c.georgescu, brian.avery, ioanax.grigoropol, jose.perez.carranza, meta.mr.watcher, meta.watcher, richard.purdie, ross.burton, sgw, tim.orling, yp.ep.watcher, yp.watcher |
| Version: | 1.8 | ||
| Target Milestone: | Future | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | Regression (Used to work) |
| Verified: | Documentation change: | Don't know | |
|
Description
Mihail Stanciu
2014-12-09 15:28:29 UTC
The issue is that opcontrol was removed in the upstream oprofile project in favour of using perf instead. The UIs therefore need to adapt to the changes in oprofile, oprofile is still installed in the images. The issue here is oprofileui is still using opcontrol and needs updating to use the perf inferface to control the data collection. This is problem something Tom or RP have the experience to resolve. Changing the documentation to Undecided since the results displayed in OprofileUi might change with the new functionalities. This may imply changing the manual and/or the tracing&profiling wiki: https://wiki.yoctoproject.org/wiki/Tracing_and_Profiling Looking at the changes, opcontrol is gone and we need to use operf. The difference is that operf remains running the whole time data is collected, the opcontrol script used to handle this for us. opserver therefore likely needs to use g_spawn_async instead of g_spawn_sync and the config command needs to just save data into the server. The ideal case of being able to quickly turn on/off profiling with low overhead (e.g. with a signal) no longer seems possible. found during 1.8_M4.rc2 testing fido:33558eacc8a2d3dce3396b9ab2fd0773ac5076bc For future reference, RP started hacking some fixes at http://www.rpsys.net/oprofileui.patch before realising just how much work is needed. Propose to defer this to M2. seems that the issue still exists in YP 2.1_M2.rc1 master/3d2c0f5902cacf9d8544bf263b51ef0dd1a7218c Porting and updating oprofileui is likely wasted time. sysprof has been taken over by the GNOME Builder maintainer (Christian Herbert) so should have a good future and shouldn't need too much engineering to support some sort of remote connection model. Alternatively, we could test and support the perf support in Eclipse, if that has remote support (or write it if required). Tim has been talking to the Eclipse people so I've CCd him for his opinion. Thanks for the reminder to test oprofile and other Linux Tools. Especially the remote parts :) I am establishing good connections in the community, so if we need to upstream patches I expect to find a workable solution. Tim, did you get anywhere with oprofile? Also, does anyone currently have a good summary of the situation in 2017? * is this still an issue we need to solve? * is eclipse relevant or should I touch base with gnome-builder folks? We have restarted working on a plugin crops/eclipse-crops to allow building and qemu in containers. Haven't dealt with profiling yet. Reassigning Jussi's bugs. eclipse has been dropped. closing |