Quoting: gurvI'm glad to see you have at least found a way to game with a good framerate.
Good luck taming that monster cpu ^_^:)

Edit:
Oh just thought about something: you could get a pretty heavy framerate penalty if NVidia's driver thread is not on the same ccx. I think I've seen that happen when fiddling on my Ryzen.
So you may have to try all the ccx pinning possibilities:
taskset -c 8-11,40-43 %command%
taskset -c 12-15,44-47 %command%
(you should fix the ram slots assignment before trying the next two as currently numa node #0 doesn't have direct access to memory)
taskset -c 0-3,32-35 %command%
taskset -c 4-7,36-39 %command%

After a few months (sic) of experiments, I found out that the best performance is on the NUMA Node #2, which has direct access to memory and GPU, hence the best cores affinity statement would be the following:
$ taskset -c 8-15,40-47 %command%

In addition, some games could make an advantage of the [Feral Interactive Game Mode](https://github.com/FeralInteractive/gamemode) tweaks:
$ gamemoderun taskset -c 8-15,40-47 %command%

Furthermore, for some specific games, the kernel might still locate some threads on a different core, if the affine ones are 100% busy. In these cases I wrote a simple script for shutting down all the other cores, which should run before the game process:

cpu=

case $1 in
"on") cpu_status=1;;
"off") cpu_status=0;;
"-h") echo "Usage: sudo gaming-cores-switch {on|off}" && exit 0 ;;
"--help") echo "Usage: sudo gaming-cores-switch {on|off}" && exit 0 ;;
*) cpu_status=1;;
esac

for i in $(seq 7 && seq 16 39 && seq 48 63) 
do
cpu=/sys/devices/system/cpu/cpu${i}/online
echo changing cpu $cpu status to $cpu_status
echo $cpu_status > $cpu
done

For setting up all the things as clean as possible, I put the script in the /usr/local/bin directory and created a new systemd service (file: /etc/systemd/system/gaming-cores-switch.service):

[Unit]
Description=Manual Switch of CPU Cores for Gaming
After=network.target

[Service]
ExecStart=/usr/local/bin/gaming-cores-switch off
ExecStop=/usr/local/bin/gaming-cores-switch on
Type=simple
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

And then used the [Services Systemd Gnome Extension](https://extensions.gnome.org/extension/1034/services-systemd/) for toggling the service from the Gnome DE, with the following configuration:


In the end, the cores enablement will look like a switch on the UI:


Of course a few other solutions can be put in place, but what I like about this one is that it feels exactly like the official [AMD Ryzen Master Utility for Windows](https://www.amd.com/en/technologies/ryzen-master), even though much more simplified.

Last edited by LordDaveTheKind on 22 Oct 2019 at 9:22 pm UTC

Quoting: LordDaveTheKind$ taskset -c 8-15,40-47 %command%

Am I understanding this correctly, basically here you tell the CPU to use the 8-15 cores and the 40-47 is their corresponding secondary threads?

Quoting: Avehicle7887

Quoting: LordDaveTheKind$ taskset -c 8-15,40-47 %command%

Am I understanding this correctly, basically here you tell the CPU to use the 8-15 cores and the 40-47 is their corresponding secondary threads?

Correct. According to the cores topology, 40-47 are the virtual secondary cores corresponding to 8-15.

Quoting: LordDaveTheKindThanks to all the people who contributed to this post.
The reason is still not 100% clear for me, though. The fact that Debian comes shipped with a Kernel which can better support my CPU (and provide a better scheduling for it) might be a hypothesis.

Well, it seems I wasn't totally wrong.

Recently I have been experiencing the same poor behaviour after "upgrading" to Debian 10 Buster. I compared the performance with the SteamOS ones (which were still perfect), and decided to perform the following experiment:

• Copy the SteamOS kernel configuration file in the Debian partition;


• Compile a custom version of the kernel in Debian with the same configuration file;


• Deploy and Run it.

With the custom kernel version the result has been awesome: 1440p-60fps at Max quality settings on all the games expected to run on these conditions.

It seems that the cracked code lies in the different kernel configuration files. I'll investigate a little more on their differences in the next days. But I believe I'm going to enjoy some thoughtless and carefree gaming for some time now.

Cheers,
Dave