AMD 3D V-Cache Optimizer Driver Headlines The x86 Platform Enhancements In Linux 6.13

[kalrish]

Are you familiar with any dynamic ways to do this? I set WINE_CPU_TOPOLOGY="16:0,1,2,3,4,5,6,7,16,17,18,19, 20,21,22,23" but that only covers the games I'm running under Proton, and it doesn't cause the OS to leave those cores alone for other processes so it could be better. Would be nice to have a daemon running that automatically manages all this, understands how to see what I'm running under Steam or Heroic, etc. While I'm wishing for magic, how about something that keeps the kernel quiet on thread #0? :-)

The only dynamic solution I've heard about is Feral's GameMode. I've never tried it, but it must be popular if the Arch Linux wiki has an article on it, and it should be good if it's popular.

If that doesn't work and you don't find another dynamic solution, you could try the following static one.

Desktop systems managed by systemd create a scope unit for each desktop application you run. You can see them with systemctl status (ran as your user). You could move Steam and Heroic –and hopefully games launched through them– to your CPU's cache cores by overriding the option AllowedCPUs on their respective scope units with a couple of user drop-ins (usually in ~/.config/systemd/user/) as described in this answer. Ideally the kernel would move non-game processes out of the cores used by your game. In that case, you wouldn't have to configure anything else and your applications would still benefit from your CPU's cache cores when you're not playing.

Otherwise, you could force non-game processes onto your CPU's frequency cores. According to systemd.special(7), systemd puts all system services in system.slice. You could override the option AllowedCPUs on that slice unit with a system drop-in (one in /etc/systemd/system/). Additionally, you could move user services to your CPU's frequency cores with a similar drop-in on user.slice. Kernel processes would not be affected and might still run on your CPU's cache cores, though. And, in any case, you'd be wasting half of your CPU while not playing.

[Scramblejams]

I've been doing that by restricting the CPU cores a cgroup's processes may run on; for example, on a 7950X3D, cores 0-7 and 16-23 belong to the CCD with 3D V-Cache. In any case, I agree with you: this new driver would be more useful if it offered the interface you describe.

Are you familiar with any dynamic ways to do this? I set WINE_CPU_TOPOLOGY="16:0,1,2,3,4,5,6,7,16,17,18,19, 20,21,22,23" but that only covers the games I'm running under Proton, and it doesn't cause the OS to leave those cores alone for other processes so it could be better. Would be nice to have a daemon running that automatically manages all this, understands how to see what I'm running under Steam or Heroic, etc. While I'm wishing for magic, how about something that keeps the kernel quiet on thread #0? :-)

[intelfx]

Would be great to know if this is accurate.

It more-or-less is. Not just this part, but the entire thing with the evolution of the amd-pstate driver so far just screams "we throw random code at the wall and see if it sticks". (Source: I've been following the development of this driver and reading every patch series posted on LKML, even if I didn't do any public reviews because I'm pretty much nobody in the kernel community.)

[Teadrinker]

I can confirm that on newest CachyOS that already has backported this driver, it does NOT work for my 7900X3D. It exists and can be set to cache, but has no effect. I use MangoHud overlay, and see no difference in core utilization between normal/extra cached cores and no improved FPS at all.
Yet Gamemode Core Parking utility has been working for me perfectly (parking the normal cores like Windows)...

[carguello2]

Can you please link the source?

https://www.phoronix.com/forums/forum/hardware/processors-memory/1507054-many-amd-cpu-feature-additions-land-in-linux-6-13?p=1507076#post1507076

[darkbasic]

Would be great to know if this is accurate.

Can you please link the source?

[pWe00Iri3e7Z9lHOX2Qx]

The 3D V-cache optimizer driver requires x86_sched_itmt_flags() to be returned in x86_die_flags() to function (i.e. let the kernel prioritize threads to 3D V-cache die), otherwise the core prioritizing scheduling would only gonna work within a single CCD rather than selecting the preferred CCD first, then selecting the highest performance cores. 7950X3D definitely needs that, it's also the whole point of this driver. But that flag is only enabled for heterogeneous configurations like Strix Point because AMD added a feature check for X86_FEATURE_AMD_HETEROGENEOUS_CORES there before returning the flag in x86_die_flags().

The whole preferred core scheduling thing on Linux is just a few AMD kernel engineers following Intel's implementation without a clue how they worked, and how to test them to ensure they work as expected.

Would be great to know if this is accurate.

[pWe00Iri3e7Z9lHOX2Qx]

There was a post in another thread that said this wasn't actually going to do anything because the logic for the checks of when to apply it were faulty.

[mrg666]

It would be great to generalize the code for heterogenous CPU schedulers applicable to both Intel and AMD CPUs, and even for ARM.

[kalrish]

It would be much more useful if we could pass it a process tree root and define whether everything under that process is scheduled for frequency or cache.

I've been doing that by restricting the CPU cores a cgroup's processes may run on; for example, on a 7950X3D, cores 0-7 and 16-23 belong to the CCD with 3D V-Cache. In any case, I agree with you: this new driver would be more useful if it offered the interface you describe.