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.
gamemoded will now load and merge settings from the following locations - arrays will merge and single settings will overwrite.
1. /usr/share/gamemode/
2. /etc/
3. $XDG_CONFIG_HOME or $HOME/.config/
4. $PWD
This allows the client to query the daemon about the status of gamemode.
Returns the following:
0 if gamemode is inactive
1 if gamemode is active
2 if gamemode is active and this client is registered
-1 if the query failed
Passing -s to gamemoded will simply query and print the current status.
Allows for more comprehensive testing when using 'gamemoded -r' as well as more reactionary program behaviour
This allows for easy requesting of gamemode and pausing for any signal
Primarily useful for simple tests, but also functionally to allow enterning and exiting gamemode manually
A much requested feature, this allows for providing custom scripts in the config file. An example in the man page is below and would trigger both a system notification, and allow control over a background crypto mining script automatically in gamemode.
[custom]
; Custom scripts (executed using the shell) when gamemode starts and ends
start=notify-send "GameMode started"
/home/me/bin/stop_ethmining.sh
end=notify-send "GameMode ended"
/home/me/bin/start_ethmining.sh
Scripts are run with system() and do not have any special privilages, as with the rest of the daemon, custom scripts that require root will need their own permissions set up externally.
This commit also renames two defines as they needed to be moved to the public interface.
This moves adding to lists and getting long values into resuable functions.
It also fixes a couple other issues in the process:
1. Logging now goes to the error channel and is labelled
2. >Max length lines are properly handled, although this should never happen since inih has a 200 limit
* Minor C cleanup
- some symbols can be made static:
1. set_gov_state
2. everything in gamemode_client.h
- daemonize() can also take a const char*, since the name is only
passed to printf() or syslog()
- prevent shadowing of variables
- use explicit (void) as parameter-list more consistently
- use some more const.
Move cast to more appropriate place and document that execv() behaves
as if args where of type const *char and we trust on that.
- example: Just use main(void), which is also an acceptable ISO-C decl
- example: Use stderr for errors
* Fix -Wold-style-declaration issue
