Created attachment 122116 [details] KSysGuard including per-process power consumption. SUMMARY When working on battery-powered devices, it would be very useful to have info about power consumption related to each process (and maybe even application). Other OS like Mac OS and Android provide such a feature in some form. I think this is a feature that Plasma should include. Other energy-related info can be provided in the future, but for the moment I'd start with this one. IDEA For the first step, a new column in the process table that reports some kind of power requirement information for the process may be sufficient. An example is provided in the shot I attached. The concept may then be extended with more info/tools, charts, etc... if there is interest. TECHNICAL PROPOSAL My researches led me to a tool named Powertop (https://github.com/fenrus75/powertop), which seems to be able to provide an estimation in Watts of the power required by a process. The tool is a command line binary based on ncurses that provides a process table with energy-related information. Powertop is written by Intel and published under GPLv2 license. It is reported to work on Linux and Android. A possible approach would be to leverage the implementation contained in Powertop and display in KSysGuard. PROOF OF CONCEPT To test the feasibility of my idea I implemented a proof of concept (the attached shot results from it). I turned the Powertop executable into a shared library (libpowertop) used as a data provider. Powertop requires root privileges, so ksysguard uses libksysguard to get the process list, which in turn uses KAuth to transparently run a helper linking to libpowertop. The helper runs for the entire lifespan of the process list and provides data. The shot I uploaded comes from my draft. CONCLUSION I'd appreciate feedback about both the feature itself and about my technical proposal. There are clearly a few technical key points that would need in depth discussion. Thanks!
Looks like a great idea. Are there any source code and build instructions available for those who want to test this feature?
At the moment I just have a draft. I can improve it a bit and share. I would like to have some feedback from the community about the key points before working more on this. Do you think relying on some fork of powertop would be a good approach? Are there licensing issues? Would you prefer to have a fork of powertop in the form of a shared library or do you prefer to integrate the code. Do you think linking to libksysguard is ok or do we want a daemon with a dbus interface instead?
Hello, this is just a draft of the architecture of what I imagined, but I guess it is simpler to get comments/critics by providing what I did. I added a few notes about the build procedure in my main repo: https://github.com/carlonluca/libksysguard. Powertop includes a training phase of a few minutes (on battery) where values are simply hidden (I guess): I'm currently missing this phase and I just provide values even if those are not probably accurate during it. I've never built the code outside my env yet, so please let me know if you see something is not working in the build phase.
Luca, the infra we talked about https://phabricator.kde.org/D23287 Let me know if it works for you I have a similar version for doing global information.
It probably is. I'll read more carefully. Do you also happen to have an example? At the moment I'm more worried about the other portion of the implementation. Multiple instances of KSysGuard are allowed, but I see only one KAuth helper process.
There's an example here: D23288, but the network stats are probably a better example. We'll have one soon. >Multiple instances of KSysGuard are allowed, but I see only one KAuth helper process. I don't see why that needs to be an issue. I'm also not convinced we need kauth, just something suid - but we can discuss that on phab nearer the time.
It is not necessarily an issue, but that means I need to know how it works. The second instance of KSysGuard calls into the existing KAuth helper? Is it creating a new thread? This is something I need to know cause it means things must be thread-safe. I excepted two helper processes. If running an executable with suid bit is allowed, it would probably be a good option. I didn't do that cause some systems do not allow it, like Android, and also I think it is ignored with SELinux. But it would be better to design first and implement after, instead of implementing, redesigning and reimplementing. Are there other parts of Plasma using suid bit? Maybe KAuth itself? I don't think any of this is a showstopper to plugin integration, but the implementation may differ, and I can't therefore go on. I'll study what you provided. Thanks!