Allow Conky, at least if compiled by the user, to subject itself to a cgroup

[LinuxOnTheDesktop]

It makes sense for a monitoring application to be limited in how much CPU it uses. Running Conky at a 'niceness' will only go so far towards that goal. For, if the system has the resources available at the relevant time, nice will let Conky use them and, on a laptop that could be bad - because of battery life and fan noise. Similarly, intervals - update_interval, update_interval_on_battery, execi periods - will only do so much.

A savy-to-very-savy user can run Conky under a 'cgroup'. But it would be good were Conky to have that ability built in, at least as a compile-time option - whereby one can specify a CPU percentage, or such like.

I have not compiled Conky - at least while paying attention - for a while; but I take it that at present cgroups are not supported.

[Caellian]

Admittedly, I'm not a savy linux user - I almost never configured process niceness besides learning about the command in uni and testing it out. I also never used cgroups. I do get what they do, I just never think of using them (even when I had a very crappy laptop).

But going through their docs, I don't see how similar functionality can be added to conky besides just update_interval.

For instance, niceness doesn't do much for conky because it's mostly a single-threaded application. I linked to man(3) which shows how it can be configured from the process itself, but it wouldn't do much. It could also cause some issues with conky not respecting update_interval because multi-threading is only used by some variables at the moment (maybe).

Support for cgroups-like feature isn't something that conky should do IMO. It would take a lot of work/code/testing to do it properly, and it could never be as good as system-level configuration because conky only has indirect information about process usage, that it gets from the system. So the system will always have more up-to-date stats to work with and can adjust resources much better. For conky, the best it can do is update_interval.

[LinuxOnTheDesktop]

Let's distinguish some scenarios.

1. Via cgroups or something similar, there is a limit to the processor time that the programs Conky launches can use, either such that (a)  there is a single limit for all those launched programs or (b) each program has its own limit.
2. Via the cgroup program together with stuff within Conky itself, Conky itself is limit to n% of processor time.

Caellian gives seemingly good reasons against 1. I was thinking not of 1 but of 2. Still, here we need another distinction.

2'. It is only Conky itself that is limited in its processor use.
2''. It is Conky itself and the processes Conky launches that are limited in their process use.

2'' seems equivalent to 1 or rather specifically to 1a. So that leaves 2' as a contender. Still, 2' might face a problem similar to the niceness problem, i.e. might have a problem with update_interval.

I have written a script that runs an arbitrary program under a cgroup that limits the program to an arbitrary percentage of processor time. So I try running Conky with that script. Thereby I could determine:

• whether so doing works at all;
• whether we end up with scenario 2'' (/1a);
• whether there is a problem with the update interval.