This commit adds two new configuration options: igpu_desiredgov and
igpu_power_threshold which allow for a different CPU governor when the
Intel integrated GPU is under load. This currently only applies to
Intel integrated GPUs and not AMD APUs because it uses the Intel RAPL
infrastructure for getting power information. If on a platform that
without an Intel integrated GPU or where the kernel does not support
RAPL, the new options will be ignored and it will fall back to the old
behavior.
One of the core principals of gamemoded to date has been that, when
playing a game, we want to use the "performance" CPU governor to
increase CPU performance and prevent CPU-limiting. However, when the
integrated GPU is under load, this can be counter-productive because the
CPU and GPU share a thermal and power budget. By throwing the CPU
governor to "performance" game mode currently makes the CPU frequency
management far too aggressive and it burns more power than needed. With
a discrete GPU, this is fine because the worst that happens is a bit
more fan noise. With an integrated GPU, however, the additional power
being burned by the CPU is power not available to the GPU and this can
cause the GPU to clock down and lead to significantly worse performance.
By using the "powersave" governor instead of the "performance" governor
while the integrated GPU is under load, we can save power on the CPU
side which lets the GPU clock up higher. On my Razer Blade Stealth 13
with an i7-1065G7, this improves the performance of "Shadow of the Tomb
Raider" by around 25-30% according to its internal benchmark mode.
Try to make API requests using the new pidfd based APIs. If getting
the pidfds fails or if the remote (daemon) does not support the new
pidfd based D-Bus API, transparently fall back to the old API.
Provide a new set of APIs with identical semantics as the existing
ByPID family of calls but instead of working with process ids, they
take pidfds, file descriptors representing processes, instead. The
fds can be translated back to pids (in the correct namespace) and
also be monitored via select/poll/epoll.
The current implementation translates them directly back to pids,
but in the future the monitoring code that watches processes (if
they are still alive) could be converted be event driven via pidfds.
Add functions to open pidfds, i.e. file descriptors representing
processes, for process ids and vice versa. Both functions work
an array of fds/pids, stop on error and return the number of
successfully handled items.
Much like the auto-closing helper for file descriptors, add a new
auto-free helper that is meant to be used with dynamically allocated
memory, a la:
autofree char *data = NULL;
...
data = malloc(size);
When data goes out of scope, cleanup_free will be called with &data,
i.e. cleanup_free(&data), which in turn will call free(3) data. In
order to work with all types, e.g. 'char *' (resulting in char **
being passed to cleanup_free) or 'int *' (resulting in int ** being
passed to cleanup_free), cleanup_free is defined to work with void *,
hence the odd-looking cast: void *target = *(void **) ptr.
Specify the include directory in the link_daemon_common dependency
and thus everything that includes that as a dependency will get
the proper include directory automatically.
There's no need in defining it at the top of the function. During
rebase, I had one `if` accessing `cl->executable` too early but we were
only storing the path in `executable` at that point.
This change avoids accessing `cl` while it might be NULL.
Signed-off-by: Kai Krakow <kai@kaishome.de>
