NUMA in 32-bit mode

[Umbrah]

Hallo,

Als een voor-onderzoekje voor een klant ben ik bezig met een onderzoek, en ik ben tegen een kleine theorie aangelopen die ik toch tegen de experts aan wil gooien. Het is helaas iets waar ik geen papers over kon vinden, noch heb ik er sowieso veel over gevonden.

De situatie is als volgt:

Er zijn een aantal blades, waarvan elke blade voorzien is van een 4- of 6-core Nehalem CPU. Elke CPU heeft z'n 3 geheugenkanalen gepopuleerd met 2GB DIMM's. So far so good, 12GB geheugen per blade van óf 8, óf 12 cores.

Voor hen die het niet weten: Nehalem heeft een on-die geheugencontroller en een Quick-path interconnect van zo'n 25gb/s die de CPU's onderling verbind en de rest van het systeem.

Noem het economie, noem het zuinigheid, maar deze systeempjes werken elk met.... 32bit Windows 7 professional. Dit om licentiekosten te besparen. Iets waar ik sympathie voor kan hebben. Een stap naar Linux is niet aan de orde, en een server Windows ook niet. Hacks zijn al helemaal uit den boze.

Deze mensen werken met specialistische systemen die in feite een beowulf-achtige opzet hebben. Simpele programma's grijpen rekentaken, gaan rekenen, en spugen hun rekentaken weer uit.

Er zit echter een limiet en ik heb zo mijn bedenkingen. De processen zijn allen identiek en trekken 100% van één core gewoon "vol". De schaling is op mijn sandy-bridge testsysteem dan ook lineair (elke thread = +96% performance, zodra ik in de hyperthreading cores schiet komt er iets van +20% bij), met een optimum op aantal cores * 2 op mijn eigen 64 bit testsysteem.

Je denkt: een simpele migratie naar een 64-bit OS zal helpen. Maar dan ben ik er nog niet. Ik heb een andere bedenking. De taken zijn nogal zwaar op het geheugen, per thread wordt er ongeveer 1 gigabyte aan geheugen opgegeten. Leuk als je een single-CPU machine hebt, maar dat zijn de werkelijke machines niet.

Ik heb helaas geen toegang tot de echte machines, noch budget om ze te kopen. Waar ik achter wil komen is het volgende:

Hoe gaat Windows 7-32 bit om met NUMA?

Deze klant omschrijft dezelfde "inkuikel" bij minder threads dan dat er aan CPU's zijn, zelfs bij threads van slechts 200mb! Mijn theorie is dat zodra er vanaf CPU0 afgeschakeld wordt, alle geheugen I/O over de QPI moet, wat een dusdanige impact geeft dat het uitvoeren van meer threads niet nuttig is.

De theorie die ik heb is dat een 32-bit Windows 7 geheugen vanaf CPU0 gaat optellen tot de magische "3GB" limiet. Leuk dat we precies 3GB op CPU0 hebben; in feite wordt CPU1 dus niet voorzien van geheugen. Taken die op CPU1 draaien zullen dus via de QPI het geheugen van CPU0 moeten aanspreken, waardoor de performance werkelijk verliest. Helaas kan ik dit niet testen, en hoewel ik me er bewust van ben dat Windows dergelijke taken wel degelijk slim kan adresseren op OS-basis, probeer ik nog een extra punt vóór een migratie naar een 64-bit OS te vinden.

Heeft iemand hier ervaring mee, of specifiek: ervaring met Windows 7 32-bit zonder PAE en een NUMA systeem?

[_JGC_]

Windows 7 doet alleen NUMA op 64bit, niet op 32bit voor zover ik weet. Verder zit je met de 4GB limiet op 32bit versies van Windows 7 (PAE of niet boeit niet, je komt niet verder dan 4GB). Ik weet niet hoe de nieuwe architectuur geheugen adresseert, maar grote kans dat je alleen 4GB van het geheugen op de 1e CPU kunt adresseren in 32bit, waardoor die 2e CPU qua overhead bij geheugentoegang in feite waardeloos is.

[Voor 37% gewijzigd door _JGC_ op 28-06-2011 19:45]

[jmzeeman]

32-bit Windows zou op zich prima NUMA moeten ondersteunen maar je zal om dit te gebruiken wel PAE aan moeten zetten, ik snap je laatste zin dan ook niet helemaal. In de praktijk slaat deze NUMA support eigenlijk helemaal nergens op aangezien ik nog nooit een NUMA systeem met minder als 4GB er in heb gezien.

Als je NUMA uit zet in de BIOS worden de pages om en om gemapped over de processors waardoor het systeem de geheugen access tijden middeld. Dit zorgt er ook voor dat elke processor evenveel geheugen dat binnen de geheugen limiet ligt heeft. Als je NUMA aanzet worden ze achter elkaar gemapped, dit zorgt er voor dat het gedrag wat jij beschrijft inderdaad mogelijk is. Dit aangezien Windows 7 32-bit een geheugenadres limiet heeft van 32-bit voor fysieke geheugen adressen ook al is PAE enabled. Hierdoor zal windows het geheugen dat door je BIOS gemapped is boven de 32-bit niet gebruiken. PAE aanzetten zorgt er wel voor dat andere geheugenbeheer functies als DEP en NUMA gaan werken.
De opties die je hebt zijn:
- 32-bit met NUMA disabled in de BIOS (soms heet dit enable node interleave of memory interleave)
- Minder geheugen plaatsen zodat het totaal onder de +-3,5Gig blijft
- Lelijke hacks met kernel patches die de limiet weg halen (kan problemen geven met sommige drivers)
- Naar 64-bit

Het blijft ook zonde van je 12GB als je op 32-bit blijft draaien ook omdat de licenties ook gewoon geldig zijn voor 64-bit. Als je NUMA wil gebruiken kan het ook belangrijk om je applicaties NUMA aware te maken anders kan het goed zijn dat NUMA je performance zelfs negatief beïnvloed. Maar als ik zie wat de toepassing is denk ik niet dat daar iets aan gedaan hoeft te worden.