Opterons e Nelahem (55xx e posteriores) Os Xeons têm uma arquitetura NUMA - cada soquete tem seu próprio barramento de memória e há um link entre os soquetes. Esse link é chamado de Hypertransport nos sistemas Opteron e Quickpath on Xeons. O G5 antecede Nelahem e ainda usa o antigo Front Side Bus, que não é uma arquitetura NUMA.
Opterons e 35xx / 55xx ou posterior Xeons podem usar um modo de endereçamento NUMA puro, onde a memória de cada soquete reside em uma seção contígua do espaço de endereço físico. Se você deseja executar um aplicativo que esteja ciente do NUMA (por exemplo, suporte para afinidade do processador), você pode configurar o sistema para ser executado nesse modo.
Sistemas desse tipo também têm um modo legado em que páginas individuais de 4K alternam entre os soquetes, de modo que o acesso à memória é bem misturado entre os soquetes. Isso tem uma pequena sobrecarga de desempenho, já que metade de todos os acessos à memória precisam passar pelo barramento Hypertransport para o outro soquete (Quickpath no caso do Xeons). No entanto, a maioria dos acessos será armazenada em cache, portanto, a sobrecarga de desempenho é relativamente pequena.
Este modo permite que os sistemas executem aplicativos não compatíveis com NUMA de forma eficiente, e normalmente é o modo padrão no qual o sistema é inicializado. Normalmente, você pode configurá-lo na BIOS.
Seu G5 não funcionará no modo NUMA porque possui uma arquitetura de barramento frontal. O FSB é um barramento único compartilhado pela memória e por todos os soquetes do processador, por isso tem características de acesso à memória uniforme , ou seja, não o NUMA. Não tenho conhecimento de nenhum aplicativo wintel ou lintel que dependa de uma arquitetura NUMA; É provável que o aplicativo não precise de NUMA, mas o suporte, se presente. Você provavelmente ainda pode executar o aplicativo no seu sistema G5 mais antigo. Se isso é relevante depende da aplicação e do que você deseja alcançar.
Suporte a NUMA em aplicativos
Alguns aplicativos (o SQL Server é um exemplo) podem obter benefícios significativos de desempenho, otimizando a memória, a utilização de E / S e o agendamento, a fim de minimizar as penalidades para o acesso não local. A implementação do suporte a NUMA em um aplicativo requer que as instalações de suporte estejam disponíveis no sistema operacional, como:
-
Afinidade do agendador: um encadeamento pode ser colocado em um conjunto que tenha preferência para agendar em um ou em um grupo de processadores. Observe que o NUMA pode ter mais de um processador em um único barramento de memória - no caso de um Opteron ou Xeon de vários núcleos, os núcleos em um único die compartilham o mesmo barramento. Isso permite que o encadeamento solicite memória local ou use pools de memória locais para o pool de CPU. Além disso, quando um encadeamento é mantido em uma CPU local, ele minimiza a sobrecarga de cache à medida que o encadeamento é agendado - o conjunto de trabalho é apenas o conjunto de encadeamentos de trabalho que usa esse núcleo específico.
-
Afinidade de memória: um segmento pode solicitar memória e especificar que deve ou deve estar disponível da memória local para um soquete. Manter a memória e o uso da CPU no mesmo barramento minimiza a sobrecarga do acesso à memória não local. A sobrecarga não é tão grande em sistemas NUMA modernos, mas o acesso não local foi muito mais lento em sistemas mais antigos, como o equipamento Sequent inicial.
-
Afinidade de E / S: Os barramentos periféricos podem ser vinculados a uma CPU local, portanto, o manuseio de E / S pode ser planejado em processadores que estão próximos da E / S. A maioria dos sistemas NUMA tem múltiplos barramentos de E / S, portanto, agendar manipuladores de interrupção e DMA para a memória local oferece alguma vantagem no desempenho de E / S.