回答:
OpteronsとNelahem（55xx以降）XeonにはNUMAアーキテクチャがあります-各ソケットには独自のメモリバスがあり、ソケット間にリンクがあります。このリンクは、OpteronシステムではHypertransportと呼ばれ、XeonsではQuickpathと呼ばれます。G5はNelahemよりも前のものであり、NUMAアーキテクチャではない古いフロントサイドバスを引き続き使用しています。
Opteronおよび35xx / 55xx以降のXeonは、純粋なNUMAアドレッシングモードを使用できます。このモードでは、各ソケットのメモリは物理アドレススペースの連続したセクションに存在します。NUMA対応のアプリケーション（プロセッサアフィニティのサポートなど）を実行する場合は、このモードで実行するようにシステムをセットアップできます。
このタイプのシステムには、個々の4Kページがソケット間で交互に行われるレガシーモードもあるため、ソケット間でメモリアクセスが細かく混合されます。これは、すべてのメモリアクセスの半分がHypertransportバスを介して他のソケット（Xeonの場合はQuickpath）に到達する必要があるため、わずかなパフォーマンスオーバーヘッドがあります。ただし、ほとんどのアクセスはキャッシュされるため、パフォーマンスのオーバーヘッドは比較的小さくなります。
このモードにより、システムは非NUMA対応アプリケーションを効率的に実行できます。通常は、システムが起動するデフォルトのモードです。通常、これはBIOSで構成できます。
G5は、フロントサイドバスアーキテクチャを備えているため、NUMAモードで実行されません。FSBはメモリとすべてのプロセッサソケットで共有される単一のバスであるため、NUMAではなく均一なメモリアクセス特性を持っています。NUMAアーキテクチャに依存するwintelまたはlintelアプリケーションは知りません。アプリケーションがNUMAを必要としないが、存在する場合はそれをサポートする可能性があります。おそらく、古いG5システムでアプリケーションを実行できます。これが関連するかどうかは、アプリケーションと何を達成したいかによって異なります。
アプリケーションでのNUMAサポート
一部のアプリケーション（SQL Serverなど）は、メモリ、I / O使用率、およびスケジューリングを最適化して、非ローカルアクセスのペナルティを最小限に抑えることにより、パフォーマンスの大幅な向上を実現できます。アプリケーションにNUMAサポートを実装するには、オペレーティングシステムから次のようなサポート機能を利用できる必要があります。
スケジューラアフィニティ：スレッドは、1つまたはグループのプロセッサでスケジュールするプリファレンスを持つプールに配置できます。NUMAは単一のメモリバス上に複数のプロセッサを持つことができます-マルチコアOpteronまたはXeonの場合、単一のダイ上のコアはすべて同じバスを共有します。これにより、スレッドはローカルメモリを要求したり、CPUプールに対してローカルなメモリプールを使用したりできます。また、スレッドがローカルCPUに保持されると、スレッドがスケジュールされているため、キャッシュスラッシングが最小限に抑えられます。ワーキングセットは、その特定のコアを使用するスレッドのワーキングセットにすぎません。
メモリアフィニティ：スレッドはメモリを要求し、ソケットのローカルメモリから使用可能または使用可能であることを指定できます。同じバスでメモリとCPUの使用率を維持すると、非ローカルメモリアクセスのオーバーヘッドが最小限に抑えられます。最近のNUMAシステムではオーバーヘッドはそれほど大きくありませんが、初期のSequentギアなどの古いシステムでは非ローカルアクセスがはるかに遅くなりました。
I / Oアフィニティ：周辺バスをローカルCPUに結び付けることができるため、I / Oに近いプロセッサでI / O処理をスケジュールできます。ほとんどのNUMAシステムには複数のI / Oバスがあるため、割り込みハンドラーとDMAをローカルメモリにスケジュールすると、I / Oパフォーマンスが向上します。