Nu har jag surfat runt och letat efter de antydda ”foldare” med instabilt Phenomsystem utan framgång. En ägare till 2,2 GHz Phenom säger att han kan överklocka den till 3 GHz och köra alla vanliga program, men om han ”foldar” så kan han inte överklocka den högre än 2.8 GHz utan att råka ut för låsningar.
Låt oss anta att detta är signifikant för de Phenom som har sålts hitintills. Varken Intel eller AMD stödjer officiellt överklockning även om båda vet att det förekommer. De kan omöjligen hållas ansvariga för att någon av deras produkter inte kan överklockas lika mycket om man kör ett specifikt program. Att ens antyda något sådant är löjligt.
Det verkar finnas mycket folk runt omkring som vill att AMD misslyckas. Vissa tom lossas vara AMD-fans. Dessa Intel-fanboys inbillar sig att Intel kommer att fortsätta att spotta ut nya processorer med rasande fart till låga priser om konkurrens saknas. Icke sa Nicke. Dream on…
De som antyder att fixen till Linux inte är säker, borde ta en stund och läsa om vad problemet egentligen handlar om. Errata 298 som Linuxfixen baseras på ger samtliga detaljer. Jag gör ett försök att sammanfatta det nedan.
Alla arkitekturer med flera cachenivåer kan momentant ha flera kopior av ”samma” data. Varje kärna har en egen L2-cache medan L3-cachen är gemensam för alla kärnor. För att systemet skall veta vilken kopia som är den färskaste vid varje specifikt ögonblick så finns specifika flaggor som sätts av de olika processerna och som analyseras av varje pågående process vid accessbegäran. Buggen kan endast aktiveras under ett mycket kort tidsfönster då flera olika processer begär innehållet i ett specifikt minnesområde i L3-cachen. Den nya informationen måste dessutom ha nått L3-cachen ”före” den når L2-cachen som tillhör den process som begärt den. Data som begärs från RAM kopieras per automatik till den L2-cache som tillhör den aktuella processen samt till L3-cachen för gemensam access. Däremot sker inte detta exakt samtidigt. L2-cachen körs med samma hastighen som sin kärna medan L3-cachen styrs av samma klocka som nordbryggan. Buggen kan endast aktiveras om en annan process begär data som ligger i den minnesrad i L3-cachen som redan blivit ändrad innan access- och/eller dirty-flaggorna är satta. Den inbyggda logiken uppfattar detta som ”en omöjlighet” och reser upp flaggan som säger att man inte kan lita på data som finns i L3-cachen överhuvudtaget. Detta i sin tur leder till den låsning som beskrivs.
Som jag ser det, handlar problemet i grunden om timingsskillnader. Fixen löser problemet genom att se till att man kombinerar innehållet i andra flaggor ”för samma betydelse i förväg” så att om en annan process (som körs av en annan kärna) skulle begära data som tidigare fanns i den relevanta L3-cacheraden innan flaggorna är satta inser att informationen den behöver inte längre finns i L3 utan skall hämtas från RAM. Problemet löst.
Hela denna diskussion påminner mig om Pentium buggen på 90-talet som det ventilerades om överallt tills man nästan kräktes. När man sedan analyserade vad buggen egentligen handlade om så insåg man att det är betydligt lättare att få 7 rätt på lotto än att den buggen någonsin skulle aktiveras. Tror ni att folk brydde sig. Snacket fortsatte tills ”intressenterna” tröttnade på att lyssna på sin egen röst.
Hare/PeSi