Out of the box on most distros, both of these steps will fail (renicing
requires permission which may need adjustment to limits.conf, and the
upstream kernel does not support SCHED_ISO).
Explicitly state this in the error messages to hopefully reduce user
confusion as to why these might be failing.
When there are not valid standard file descriptors then strange things
can happen. When new file descriptors are opened, they will take the
place of the former standard file descriptors and when e.g. somebody
calls printf() they will write to some file descriptor that is not
prepared for it. This would already happen during PLOG_MSG() in
gamemoded.
Actually this also causes a SIGABRT when calling gamemoded like this:
```bash
gamemoded -d
```
This is due to a bug [1] in systemd that causes an assertion to be
triggered. This shows that file descriptor zero is in this case being
replaced by a UNIX domain socket representing the connection to the
D-Bus session bus.
Therefore instead of just closing the standard file descriptors, replace
them by appropriate file descriptors refering to /dev/null.
[1]: https://github.com/systemd/systemd/issues/8080
The reason for setting umask in a daemon is to get a defined umask value
instead of whatever the calling user had configured. A umask of zero is
dangerous, however, because it can easily cause world-readable and
world-writeable files when oblivious code is involved that specified
0777 during open() calls, wanting to grant the user full control of the
resulting file mode.
Currently the daemon shouldn't be creating any new files so this is not
a matter. This could change in the future, however.
Games built against a new gamemode_client.h will fail to work with older
GameMode installations without this change. There are no ABI changes right
now so just attempt to load the old unversioned path if loading the
versioned one fails.
In order to be safe for future ABI changes and to fulfill packaging
requirements for e.g. Fedora, provide libtool like versioning for
both libraries, i.e. libgamemode and libgamemodeauto.
To ease development, create a gamemode.pc and a gamemode-auto.pc
file, that other projects can use integrate with gamemode. The
former if they want to integrate at the source level and the latter
if the automatic integration is preferred.
Always install the dbus service file and specify the systemd
unit file in it. This makes the service dbus-activatable and
thus we don't need to explicitly enable it (also we have one
less daemon running, if it is not needed).
Warn the user about adjusting `SCHED_ISO` to too high CPU usage values
as it may render the OS unresponsive.
Signed-off-by: Kai Krakow <kai@kaishome.de>
Depending on the local system architecture and the game architecture,
changes to the scheduling may result in priority inversion which has
counter-intuitive effects on performance. Let's document these to give
the user a chance to detect and fix this problem.
Signed-off-by: Kai Krakow <kai@kaishome.de>
This commit applies the configured nice value to the client. It accepts
values from 1 to 20, the negated value is applied as a nice value.
Negation was chosen due to limits of the configuration parser. Since low
priority values (0 to 19) make no sense in the scope of GameMode, this
is a safe approach.
Signed-off-by: Kai Krakow <kai@kaishome.de>
This commit adds configuration support for the renice value and amends
documentation and examples. This commit by itself does nothing, the
following commit is needed to actually apply the new settings.
Signed-off-by: Kai Krakow <kai@kaishome.de>
This commit adds a simple heuristic to auto detect whether to use
SCHED_ISO or not. It does this by looking at the number of cores:
According to some reports by users of SCHED_ISO and an explanation by
Con Kolivas, games running busy loops and running on too few cores might
start fighting with scheduling of the graphic driver, leading to
priority inversion. This results in actually lower performance.
So let's only enable SCHED_ISO on at least four cores.
The user can still force SCHED_ISO on or off by setting the
configuration value. All other values (or none) will apply heuristics.
Signed-off-by: Kai Krakow <kai@kaishome.de>
This adds support for a new configuration option "softrealtime" to be
read from the general section. This commit alone does nothing, the
following commit adds actually making use of the value.
Signed-off-by: Kai Krakow <kai@kaishome.de>
Kernels that support SCHED_ISO scheduling policy can give processes soft
real time support. This improves latency without compromising system
stability. See https://lwn.net/Articles/720227/.
This commit adds support for setting this policy with a safe fall back if
kernel support is lacking by just ignoring the error condition.
Additionally, it also tries to raise the nice priority of the game to -4
to give it a slight IO and CPU priority over other background processes.
This needs PAM adjustments to allow users raising priority to certain
levels. If it doesn't work, the fall back strategy is also ignoring the
error condition. See /etc/security/limits.conf.
Kernels that currently support SCHED_ISO include kernels with Con
Kolivas MuQSS patchset (likely the CK patchset). This patchset is
generally recommended for desktop machines but usually not found in
standard distribution kernels due to lack of widespread stability tests.
Signed-off-by: Kai Krakow <kai@kaishome.de>
As seen in Issue #45 (thanks OlliC)
This can be placed in ~/.local/share/applications/ to allow easier (re)launching of gamemode, in particular when the DISPLAY param is needed
Rather than when gamemoded is started. As see in Issue #52.
A small refactor here to ensure things stay consistent, especially
to stop storing a pointer from get_gov_state that might have had
it's memory changed at some point, confusingly.
