Testing showed that wine processes may provoke some concerning logs
multiple times. Let's explain this a little more so no questions from
worried users show up.
Signed-off-by: Kai Krakow <kai@kaishome.de>
Returning a bool is not useful if we want to create some log information
from this. It now returns NULL or a client pointer which is compatible
with all of the current users.
When dereferencing the returned pointer, a read lock must be acquired
around using the returned result as the client may be deallocated from
heap otherwise.
Signed-off-by: Kai Krakow <kai@kaishome.de>
Be careful using this as it may introduce some non-obvious pitfalls.
This saves us from a heap allocation in some code locations.
Signed-off-by: Kai Krakow <kai@kaishome.de>
This function can look up arbitrary environment variables from a running
PID (given we have access permissions which should be usually true).
Signed-off-by: Kai Krakow <kai@kaishome.de>
Let's use our new safe_snprintf() helper. It's designed to make
thread-safe usage easy and will also be used by the next commits.
Reported-by: Alex Smith <alex@alex-smith.me.uk>
Signed-off-by: Kai Krakow <kai@kaishome.de>
GameMode can do a pretty expensive lookup function now for the exe.
Let's spare some CPU cycles by detecting a duplicate PID early. Nothing
makes use of the exe path at this stage.
Signed-off-by: Kai Krakow <kai@kaishome.de>
When running wine games, there's good chance the executable is already
gone when GameMode decided to add it to the list. Let's silently bail
out here. It probably grabs a non-matching PID anyway in this moment.
Signed-off-by: Kai Krakow <kai@kaishome.de>
During finding the cause of an issue, we discovered bad interactions
with other resource management daemon that may be running at the same
time and may interfere with GameMode's ability to properly set
scheduling parameters of the process. Usually, this results in EPERM
(instead of EINVAL for lacking kernel support). It also means that the
other daemon is leaking wrong scheduling settings into the games with
negative performance impacts (quite the opposite of what the user wanted
to achieve). So we should give some valuable hints.
This commit improves logging by detecting the error situation and giving
context-based hints on what to do next. To keep logging verbosity low,
the hint is only logged once per error code.
Closes: https://github.com/FeralInteractive/gamemode/issues/68
Signed-off-by: Kai Krakow <kai@kaishome.de>
This commit allows changing the io priority of the client to a value
specified in the configuration file. That can possibly reduce lags or
latency when a game has to load assets on demand and you have background
IO activity running (or other concurrent IO).
Signed-off-by: Kai Krakow <kai@kaishome.de>
We should not leak `SCHED_ISO` into children processes. This is obviously
a no-op if launchers use the `LD_PRELOAD` method because every child would
also preload the gamemode library (except they patch the environment
before forking).
But for games supporting gamemode natively, this prevents leaking the
scheduler settings into child processes which is important because it
children may create high CPU usage which counterfeits the original idea
of this.
Apparently, this won't work for the nice value except we would intercept
the libc forking functions (which would be possible but not very
transparent and prone to compatibility problems). However, if we
implemented it, it shouldn't be part of this commit anyway.
Signed-off-by: Kai Krakow <kai@kaishome.de>
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.
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 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>
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>
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.
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
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.
