Bug 410902

Summary: Add per process power-related information in the process table
Product: [Unmaintained] ksysguard Reporter: Luca Carlon <carlon.luca>
Component: generalAssignee: KSysGuard Developers <ksysguard-bugs>
Status: RESOLVED UNMAINTAINED    
Severity: wishlist CC: kde, nate
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: KSysGuard including per-process power consumption.

Description Luca Carlon 2019-08-14 16:48:22 UTC 
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!
Comment 1 2wxsy58236r3 2019-08-15 01:57:57 UTC 
Looks like a great idea. Are there any source code and build instructions available for those who want to test this feature?
Comment 2 Luca Carlon 2019-08-15 13:49:21 UTC 
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?
Comment 3 Luca Carlon 2019-08-16 14:04:37 UTC 
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.
Comment 4 David Edmundson 2019-08-20 11:07:47 UTC 
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.
Comment 5 Luca Carlon 2019-08-20 11:31:52 UTC 
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.
Comment 6 David Edmundson 2019-08-20 11:51:04 UTC 
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.
Comment 7 Luca Carlon 2019-08-21 11:24:04 UTC 
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!
Comment 8 Christoph Cullmann 2024-09-23 21:01:13 UTC 
ksysguard is no longer maintained, in Plasma 6 there is the Plasma system monitor for this task.

If your wish is still valid for the Plasma 6 replacement, please re-open and we can move this bug to the new product, thanks!