Enligt AMD är de inte separerade klockdomäner för just L3, de är separerade enbart för diverse low power och sleep states, detta gäller vid manuell frekvens styrning, vid automatisk genom PB kan det dock styras fritt för varje kärna och är helt separerade, om detta beror på en underlig programmering av just manuell frekvensstyrning eller om PB i sig själv förhindrar manuell styrning på annat sätt vet jag icke. Det får du fråga AMD om.
Då AMD säger det markerade, kan du länka till informationen.
Om det är sant är det väldigt intressant givet att det skulle medföra att alla kärnor delar frekvensdomän (då de delar den med en delad L3$).
Dels verkar det vara en minst sagt märklig design för något man från start tänkt köra i bärbara där perf/W är väldigt viktigt (Intel hade ett tag inte möjlighet att styra frekvens per kärna, men det var något man var medveten om var suboptimalt men en laptop på den tiden hade två kärnor så inte superstort problem).
Dels skulle det verkligen sätta ett gäng frågetecken kring det jag sett på mitt system (se nedan).
Du har däremot tokfel att kärnor inom samma CCX kan ha olika frekvens vid manuell frekvensstyrning, det gäller enbart vid auto/styrt av PB, du kan testa detta mycket enkelt själv.
Förutsatte att du skulle svara något likt detta. Men grejen är att jag explicit testade om det var möjligt innan jag postade ovan. Så här ser topologin ut på min 3900X under Linux
Notera specifikt att kärna #0, #1 och #2 alla ligger i samma CCX.
I Linux kan man låta ett program styra frekvensskalningen. API:et för detta gör det även möjligt att styra frekvensen för enskilda kärnor direkt från skalet. Jag satt då manuellt olika frekvens på kärna #0, #1 och #2.
Detta är vad turbostat då visar. Detta program, till skillnad från de flesta andra, mäter frekvensen i stället för att läsa ut den från något specifikt ställe. För att mäta frekvensen kan man använda x86 TSC instruktion då den har en fixerad frekvens, oberoende av CPU-frekvens, på moderna x86 CPUer. Man ser här att TSC-frekvensen hos 3900X är 3793 MHz i mitt fall.
turbostat version 17.06.23 - Len Brown <lenb@kernel.org>
CPUID(0): AuthenticAMD 16 CPUID levels; family:model:stepping 0x17:71:0 (23:113:0)
CPUID(1): SSE3 MONITOR - - - TSC MSR - -
CPUID(6): APERF, No-TURBO, No-DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, No-EPB
CPUID(7): No-SGX
cpu0: POLL: CPUIDLE CORE POLL IDLE
cpu0: C1: ACPI FFH INTEL MWAIT 0x0
cpu0: C2: ACPI IOPORT 0x414
cpu0: cpufreq driver: acpi-cpufreq
cpu0: cpufreq governor: userspace
cpufreq boost: 1
Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz IRQ C1 C2 C1% C2%
0 0 1 0.05 2396 3793 89 38 66 31.27 68.69
0 12 1 0.06 2396 3793 123 38 77 16.68 83.27
1 1 1 0.04 3612 3793 79 30 57 10.74 89.23
1 13 1 0.04 3605 3793 110 40 66 4.07 95.89
2 2 1 0.05 2051 3793 82 21 72 15.66 84.29
2 14 1 0.05 2052 3793 112 61 54 13.02 86.94
Precis som förväntat är frekvensen samma för #0 - #12, #1 - #13 samt #2 - #14 då dessa är samma fysiska kärna men olika SMT-trådar. Men det är alltså olika frekvenser (som jag satt manuellt) på de olika kärnorna trots att de sitter i samma CCX.
Bara för att vara riktigt 100 % säker att det inte var en bug i turbostat körde jag också samma enkeltrådade program på CPU-tråd #0, #1 och #2 parallellt. Helt förväntat resultat givet respektive kärnas frekvens, d.v.s. tiden att köra programmet skilde sig proportionellt mot frekvens.
Fast allt ovan är egentligen onödigt givet att du är helt med på att PB kan medföra olika frekvens inom samma CCX. Det i sig "bevisar" att kärnorna måste köra på sina egna frekvensdomäner (och de kör även på sina egna spänningsdomäner, för är möjligt att manuellt sätta olika P-state på kärnor i samma CCX).
Sen exakt av ovan AMD gör tillgängligt i sina program är en annan fråga, men HW är kapabel till det då Linux inte kan ändra på den delen
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer