Het is niet alleen een OS kwestie.
Nee, de BIOS en gebruikte chips op het moederbord (graphics tunnel en I/O tunnel bv) zullen er natuurlijk ook mee om moeten kunnen gaan. Maar voor wat betreft de software is het echt een OS kwestie - de apps hoeven er in principe geen enkele rekening mee te houden.
NUMA is iets heel speciaals.
Mwa, speciaal... Het bestaat al vrij lang en is eigenlijk een heel logisch iets. Dat het nu pas doorsijpelt naar de "schamele" workstation / desktop markt betekent niet dat het persé speciaal is

NUMA staat ook ervoor dat een processor op niet symmetrische manier toegang heeft tot het geheugen. Het is dus een NUMA machine en niet SMP.
Nogmaals: Het 'symmetrisch' uit SMP slaat op de taken die de CPU's uit kunnen voeren. Het slaat niet op het niet uniform zijn van het geheugen.
Voor het al dan niet uniform zijn van het geheugen hebben we namelijk de termen 'UMA' en 'NUMA' uitgevonden.
Wat jij niet door lijkt te hebben is het volgende:
SMP en NUMA hebben niets met elkaar te maken.
In de praktijk zijn NUMA systemen bijna altijd ook SMP, maar zelfs dat is geen verplichting.
Je hebt uniproc systemen die UMA zijn (de meeste PCs), je hebt uniproc systemen die NUMA zijn (komen niet voor in de praktijk), je hebt SMP systemen die UMA zijn (dual P3s en Xeons bv), en je hebt SMP systemen die NUMA zijn (zware SGI bakken bijvoorbeeld, of dual Opteron systemen).
SMP en NUMA sluiten elkaar dus niet uit. Een dual Opteron systeem is SMP, omdat het om twee identieke CPU's gaat die gelijke taken verrichten. Een dual Opteron systeem is ook NUMA, omdat het adresseerbare geheugen niet uniform is.
Nou wordt met de term "SMP" soms "klassieke SMP" bedoeld, als in: "SMP zonder NUMA", maar technisch gezien is dat niet correct.
Je kunt dus wel zeggen dat de processors zelf symmetrisch zijn, maar het systeem op zich is asymmetrisch.
Vandaar dus ook dat een dual opteron NUMA is.
Hoe kun je een systeem nou NUMA noemen als het "systeem op zich asymmetrisch is"? NUMA gaat namelijk specifiek over het geheugen alleen, niet over "het systeem op zich".
Edoch, op het moment dat de processors weer een factor zoveel sneller worden zullen ook deze latencies niet zo'n indruk meer maken en zal software wel degelijk SPECIAAL gemaakt moeten worden om goed hier op te lopen.
Nee. Het is een OS issue.
Het OS dient het geheugen van een process / thread bij de CPU in te delen waar dat process / thread in kwestie op draait.
Als process A op CPU 0 draait, dan dient het OS het door process A gebruikte geheugen ook in het geheugen bij CPU 0 te alloceren. Als process A verhuisd wordt naar CPU 1 (om welke reden dan ook), dan moet het OS het geheugen overpoten naar het geheugen bij CPU 1 (of althans, dat zou meestal het verstandigst zijn).
Dit is iets waar applicaties zich niet mee bezig moeten houden. Sterker nog, dit is iets waar applicaties niet eens invloed op uit kunnen oefenen (tenzij het OS in kwestie controle daarover toelaat. Maar zelfs dan is meestal een slecht idee, aangezien het OS het doorgaans echt wel beter weet).
In principe is het zo dat windows continue van processor naar processor springt. Dan krijgt een proces een slice op die cpu, dan op een andere cpu. Dat is natuurlijk op een NUMA systeem niet zo handig.
Dat doen de meeste OSsen sowieso niet (ik weet niet hoe Windows het doet), want dat heeft sowieso een negatieve impact op de performance. Als je een process telkens van de ene CPU naar de andere CPU verhuist en terug, dan vervuil je de CPU caches enorm, wat soms een ernstige performance hit oplevert.
Goede schedulers proberen dus sowieso al een process op één CPU te houden waar mogelijk.