Processors

[tuxine]

At the moment I have set:

tux ~ # cat /usr/src/linux/.config | grep MTRR
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1

Is there a recommended configuration? Are desktop and server (database) configurations different?

For any hint, I am grateful in advance

[elstaci]

Never heard of MTRR in Linux before but found some website that provides coding:

https://www.kernel.org/doc/Documentation/x86/mtrr.txt

From GITHUB which is an excellent place to go to for Linux issues such as yourself: coreboot/mtrr.c at master · cristim/coreboot · GitHub  concerning Ryzen and AMD Support for Processor : Support for AMD Family 17h Processors · Issue #16 · groeck/lm-sensors · GitHub

[tuxine]

Thanks for your response elstaci,

In fact, it's not a Linux problem. It's a hardware requirement, in this case Ryzen.

Quote from your link from Kernel.org:

"The AMD K6-2 (stepping 8 and above) and K6-3 processors have two

   MTRRs. These are supported. The AMD Athlon family provide 8 Intel

   style MTRRs. "

And therefore my question: How many MTRRs does a Ryzen 5 1600 have?

The hardware manufacturer / developer must know that.

(The other links are about very different topics)

Thanks anyway

[elstaci]

Your best bet is to open an AMD EMAIL SUPPORT ticket. They should be able to answer your question : Email Form

[tuxine · Accepted solution]

I found the solution by trying it.

In h17 there are a total of 8 MTRRs. Of these, 3 are used in the standard.

...

[ 0.000000] MTRR default type: uncachable

[ 0.000000] MTRR fixed ranges enabled:

[ 0.000000] 00000-9FFFF write-back

[ 0.000000] A0000-EFFFF uncachable

[ 0.000000] F0000-FFFFF write-protect

[ 0.000000] MTRR variable ranges enabled:

[ 0.000000] 0 base 000000000000 mask FFFF80000000 write-back

[ 0.000000] 1 base 000080000000 mask FFFFC0000000 write-back

[ 0.000000] 2 base 0000C0000000 mask FFFFF8000000 write-back

[ 0.000000]  3 disabled

[ 0.000000] 4 disabled

[ 0.000000] 5 disabled

[ 0.000000] 6 disabled

[ 0.000000] 7 disabled

[ 0.000000] TOM2: 0000000238000000 aka 16896M

[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT 

[ 0.000000] e820: update [mem 0xc8000000-0xffffffff] usable ==> reserved

[ 0.000000] e820: last_pfn = 0xc7e80 max_arch_pfn = 0x400000000

[ 0.000000] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [ffff950c000ff780]

[ 0.000000] Scanning 1 areas for low memory corruption

[ 0.000000] Base memory trampoline at [ffff950c00095000] 95000 size 24576

[ 0.000000] Using GB pages for direct mapping

...

Now the MTRR kernel configuration is changed to "enable" and the last 4 registers reserved for the video card:

CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=4

Now the following entry appears in dmesg: (the important entries are red)

...

[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF write-through
[    0.000000]   C0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000000 mask FFFF80000000 write-back
[    0.000000]   1 base 000080000000 mask FFFFC0000000 write-back
[    0.000000]   2 base 0000C0000000 mask FFFFE0000000 write-back
[    0.000000]   3 base 0000DF000000 mask FFFFFF000000 uncachable
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] TOM2: 0000000420000000 aka 16896M
[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[    0.000000] total RAM covered: 3568M
[    0.000000] Found optimal setting for mtrr clean up
[    0.000000]  gran_size: 64K  chunk_size: 1G  num_reg: 3      lose cover RAM: 0G
[    0.000000] e820: update [mem 0xdf000000-0xffffffff] usable ==> reserved
[    0.000000] e820: last_pfn = 0xdf000 max_arch_pfn = 0x400000000
[    0.000000] esrt: Reserving ESRT space from 0x00000000da1d8c98 to 0x00000000da1d8cd0.
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] Base memory trampoline at [        (ptrval)] 96000 size 24576
[    0.000000] Using GB pages for direct mapping

...

Now 4 MTRRs are used. The kernel can delete / edit the rapidly changing content. "Found optimal setting for mtrr clean up".

This leads to: "This can increase performance of image write operations 2.5 times or more. "

See also: cat /usr/src/linux/Documentation/x86/mtrr.txt