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

[phoronix]

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

The x86 platform driver updates were merged this week for the in-development Linux 6.13 and include some nice refinements, especially for those using AMD Ryzen on Linux...

https://www.phoronix.com/news/Linux-6.13-x86-Platform-Drivers

[MastaG]

It feels like new features are hitting the kernel much faster lately.
6.12 being LTS is already a very packed release.
6.13 feels like the cherry on top.

[Kjell]

/sys/bus/platform/drivers/amd_x3d_vcache/AMDI0101\:00/amd_x3d_mode
Writing a value to that sysfs file of "frequency" will set the frequency mode while "cache" will set the cache mode

Can this be used with regular (-X) Ryzen CPUs?

Edit: scheduling within the same L3 cache group to reduce latency would be interesting

[aviallon]

Can this be used with regular (-X) Ryzen CPUs?

In the same way you can use gasoline with a Tesla, yes.

[Scramblejams]

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.

[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.

[mrg666]

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

[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.

[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.

[darkbasic]

Would be great to know if this is accurate.

Can you please link the source?