Aspectos de Programação Paralela em Máquinas NUMA

Transcrição

1 Aspectos de Programação Paralela em Máquinas NUMA Alexandre Carissimi 1 Fabrice Dupros 2 Jean-François Méhaut 3 Rafael Vanoni Polanczyk 1 1 Instituto de Informática UFRGS Caixa Postal Porto Alegre RS Brasil 2 Bureau de Recherches Géologiques et Minières (BRGM) 3, av. C. Guillemin BP6009 Orléans Cedex2 França 3 Laboratoire d Informatique de Grenoble LIG (IMAG-ENSIMAG) Antenne Montbonnot ZIRST 51, Av. J. Kuntzmann Montbonnot St. Martin França {asc, rafaelp}@inf.ufrgs.br, mehaut@imag.fr, fdupros@brgm.fr Resumo: O desenvolvimento de aplicações paralelas de forma eficaz depende de uma série de fatores. Entre esses, pode-se citar características intrínsecas do problema a ser tratado, da plataforma de hardware disponível e do paradigma de programação empregado, memória distribuída ou memória compartilhada. Além disso, há uma forte influência do suporte dado pelo sistema operacional quanto às tarefas de escalonamento e gerência de memória, como os conceitos de afinidade e de falso compartilhamento, particularmente importantes em multiprocessadores simétricos (SMP) e em processadores multicore. Hoje em dia, os multiprocessadores dedicados ao processamento paralelo pesado apresentam um acesso não uniforme a memória (Non-Uniform Memory Access) quanto à latência e a banda passante. Isso é devido ao número de processadores que possuem e a forma pela qual a memória é distribuída entre eles. Para se obter um bom desempenho na execução de uma aplicação nessas máquinas é importante que as threads (ou processos) executem em processadores que minimizem o tempo de acesso à memória. Cabe ao sistema operacional considerar esse aspecto em suas decisões de escalonamento e na alocação de memória. Este trabalho aborda os principais conceitos relacionados com máquinas NUMA e apresenta, como estudo de casos, o suporte fornecido pelos sistemas operacionais OpenSolaris e Linux. Para ilustrar quão importante é considerar esses fatores na prática, são apresentados os resultados preliminares obtidos pela execução de uma aplicação da área de geociências (simulação sísmica) em uma máquina NUMA.

2 1 Introdução Os últimos anos têm sido marcados por avanços científicos nas mais diversas áreas do conhecimento humano as quais exigem, cada vez mais, um maior poder computacional. No decorrer desses anos, várias soluções foram adotadas para suprir essa demanda. Inicialmente, foram os supercomputadores, depois os clusters de computadores e os multiprocessadores simétricos (Simetric MultiProcessors SMP) e, mais recentemente, os processadores multicore. Com aumento do poder computacional dos computadores de prateleira (Commercial off-the-shelf COTS) e a disponibilidade dos equipamentos de interconexão, os clusters de computadores [4] se tornaram bastante populares. Porém, a desvantagem dos clusters é a necessidade de desenvolver aplicações paralelas específicas para eles, o que implica no uso do paradigma de programação por passagem de mensagens através de APIs como PVM [7] e MPI [GROP96], por exemplo. Isso exige um grau de especialização e de esforço de programação não natural para uma grande parte dos programadores. Já os multiprocessadores simétricos (SMPs) permitem o emprego do paradigma de programação por memória compartilhada, mais familiar a maioria dos programadores, e disponível por APIs de multithreading como o POSIX Threads [9] ou, ainda, OpenMP [5]. A desvantagem dos SMPs está no seu custo mais elevado e na limitação do número de processadores que o compõe. Entretanto, novamente impulsionado por uma redução de custo e pelo aparecimento de processadores multicore, os multiprocessadores cc-numa (cache-coherent Non- Uniform Memory Access) tem se tornado uma opção atrativa para o processamento de alto desempenho. Uma máquina cc-numa é composta por uma série de módulos (nós), cada um contendo um ou mais processadores (multicore ou não) com uma memória local. Esses nós são interligados por um hardware, denominado de interconect, que permite ao processador de um nó acessar memória em outro nó, formando um espaço de endereçamento único e mantendo coerência entre os dados armazenados nas diversas caches. Dessa forma é possível ter multiprocessadores com um grande número de processadores. O inconveniente nessa arquitetura é que o tempo de acesso (latência) a um endereço de memória de outro nó é menor que à memória local. Isso faz com que acessos locais sejam mais rápidos, portanto, com um melhor desempenho. É essa característica que confere o nome NUMA a essas máquinas. Em tais plataformas de hardware, é importante que o sistema operacional considere a localização física dos processadores e das áreas de memória em suas decisões de escalonamento e de alocação de memória. O Linux e o OpenSolaris são dois exemplos de sistemas operacionais que oferecem suporte para máquinas NUMA. Ambos constroem abstrações de grupos de recursos (processadores e memória) de acordo com um critério de latência de acesso à memória e usam essas abstrações no escalonamento e na alocação de memória. Além disso, esses dois sistemas ainda disponibilizam aos usuários uma API que permite um certo grau de controle sobre qual nó um processo (ou thread) deve ser escalonado e de onde a memória deve ser alocada. Isso pode ser útil para realizar ajustes finos na execução de uma aplicação, já que é comum as aplicações paralelas apresentarem tarefas com um grau de dependência e complexidade de conhecimento do próprio programador e que, dificilmente, seriam consideradas pelo sistema operacional de forma automática. O objetivo deste trabalho é mostrar a importância do suporte do sistema operacional nas decisões de escalonamento e alocação de memória no desempenho de aplicações

3 paralelas em arquiteturas NUMA. Para atingir o objetivo proposto, inicialmente, na seção 2, faz-se uma revisão das diferentes arquiteturas paralelas existentes para, na seção 3, apresentar os paradigmas de programação usados nessas máquinas. A seção 4 discute os aspectos de gerência de memória em sistemas Unix a serem considerados no caso de máquinas NUMA. Na seqüência, seção 5, são apresentados o suporte a máquinas NUMA dos sistemas operacionais Linux e OpenSolaris. Na seção 6, para demonstrar na prática a importância de considerar a latência e banda passante da memória no desempenho de aplicações paralelas, discute-se os resultados preliminares obtidos pela execução de uma aplicação da área de geociências (simulação sísmica) em uma arquitetura NUMA. Por último, a seção 7, conclusão, onde é feito um resumo e algumas considerações finais sobre máquinas NUMA. 2 Arquiteturas paralelas Tradicionalmente, os sistemas operacionais são organizados em torno de um conceito fundamental: o processo. Segundo sua definição mais clássica, um processo é uma abstração que representa um programa em execução [18]. Um processo possui um fluxo de controle (thread) que fornece a ordem em que as instruções são executadas sobre um conjunto de dados. Para se obter processamento paralelo é necessário que, de alguma forma, vários processos ou fluxos de controle (threads) sejam executados simultaneamente. Isso só é possível com o auxílio de hardware. Existem diferentes formas de se projetar máquinas voltadas à execução paralela de vários fluxos de controle, definindo as denominadas arquiteturas paralelas. Para melhor compreender o tipo de paralelismo a ser explorado, Flynn [6], em 1972, propôs uma taxonomia que classificava as máquinas de acordo com uma combinação de duas dimensões. A primeira dimensão é o número de fluxos de instruções (instruction stream) que uma máquina pode executar em um determinado instante de tempo t. A segunda dimensão é a quantidade de fluxos de dados (data stream) que são processados em um mesmo instante de tempo t. Considerando que em cada uma dessas duas dimensões é possível ter duas opções, único fluxo (single) ou vários fluxos (multiple), obtém-se as quatro combinações fornecidas na figura 1. Figura 1 A taxonomia de Flynn

4 Os computadores de fluxo único de instruções, fluxo único de dados (single instruction, single data - SISD) são as máquinas de Von Neuman tradicionais baseadas em processadores como um Intel 80486, onde um processador busca uma instrução por vez e a executa sobre um único dado. Se o hardware permite que uma mesma instrução seja feita sobre um conjunto de dados, temos os computadores de fluxo único de instruções, fluxo múltiplo de dados (single instruction, multiple data - SIMD). Um exemplo típico dessa classe de máquina são os processadores matriciais, comuns em aplicações de tratamento de imagens onde uma mesma instrução pode ser aplicada a um conjunto de pixels. Um computador de fluxo múltiplo de instruções, fluxo único de dados (multiple instruction, single data - MISD) seria capaz de executar um conjunto de instruções sobre um mesmo dado. Foi empregado o condicional (seria) porque, na prática, até hoje, não existe nenhuma máquina com essa capacidade, ficando apenas como uma classe teórica. Por fim, os computadores de fluxo múltiplo de instruções, fluxo múltiplo de dados (multiple instruction, multiple data) que constituem a plataforma de computação paralela mais comum hoje em dia. Os multicomputadores, os multiprocessadores e os processadores multicore são representantes típicos dessa classe. Em todos eles, em um dado instante de tempo, existem múltiplas unidades de processamento completamente independentes que realizam, cada uma, um fluxo de instruções sobre um fluxo de dados. O contexto de estudo deste trabalho é justamente sobre máquinas MIMD. Entretanto, a classificação de Flynn não é a mais adequada por não salientar um ponto de fundamental importância para o desenvolvimento de programas paralelos para essa classe de máquinas: o acesso à memória. É possível classificar as máquinas MIMD de acordo com o tipo de compartilhamento de memória em duas categorias [19]: Fortemente acoplada (tightly coupled): sistemas onde existe um único espaço de endereçamento compartilhado por todos os processadores. Nesse caso, a comunicação entre diferentes processadores ocorre de forma implícita através de instruções de escrita e leitura em posições de memória: um processador escreve em uma posição x (store x) e outro processador lê essa mesma posição (read x) Fracamente acoplada (loosely coupled): nesse sistema, cada processador tem seu próprio, e privativo, espaço de endereçamento. Aqui, a comunicação entre processos só é possível através de primitivas de troca de mensagens como send e receive. Tipicamente, os sistemas fortemente acoplados são denominados de sistemas de processamento paralelo e os sistemas fracamente acoplados de sistemas distribuídos. Também é comum, respectivamente, o emprego dos termos multiprocessadores e multicomputadores. Outro ponto interessante a destacar nos sistemas fortemente acoplados e fracamente acoplados é quanto à localização física da memória. A figura 2 [16], apresenta uma visão da classificação das arquiteturas paralelas segundo o tipo de compartilhamento de memória e a sua localização física.

5 Figura 2 Classificação de máquinas segundo compartilhamento de memória Em um sistema fortemente acoplado todos os processadores acessam, através de uma malha de interconexão, um mesmo espaço de endereçamento compartilhado. Dependendo da localização física da memória em relação aos processadores, o tempo de acesso a uma posição de memória pode ser uniforme ou não. Surge então as arquiteturas denominadas de UMA (Uniform Memory Access) e NUMA (Non-Uniform Memory Access). Uma máquina UMA é caracterizada por fornecer um tempo de acesso idêntico a todas posições de memória para todos os processadores do sistema. Isso é típico das máquinas multiprocessadores simétricos (SMP) onde existe um único banco de memória que é acessado por todos os processadores do sistema. Já em um máquina NUMA, a memória é fisicamente composta por vários bancos de memória, podendo estar, cada um, vinculados a um processador. Nesse caso, quando o processador acessa a memória que está vinculada a si diz-se que houve um acesso local. Se o acesso for à memória de outro processo, ocorre um acesso remoto. Os acessos remotos são mais lentos que os acessos locais já que é necessário passar pela malha de interconexão. A figura 3 ilustra esses casos. Figura 3 Arquiteturas (a) UMA e (b) NUMA com acesso local e remoto

6 Um outro ponto importante nas máquinas NUMA diz respeito à memória cache. É comum, por questões de desempenho, cada processador possuir uma memória cache. Imagine agora a seguinte situação: o processador P 0 acessa a memória M 1 vinculada ao processador P 1. Após esse acesso, P 0 mantém em sua memória cache uma cópia do dado da posição de memória acessada em M 1, novas referências (leituras ou escritas) de P 0 a essa posição será feita nessa cópia em cache. O que ocorre se durante os acessos feitos por P 0 a sua cache o processador P 1 mudar o valor dessa posição de memória? Tem-se um problema de coerência de cache (cache coherence). Para resolvê-lo é necessário invalidar a cache de P 0 para forçá-lo a buscar o novo valor na memória M 1. As máquinas cc-numa (cache coherent NUMA) são projetadas para garantir a coerência entre o valor armazenado em uma cache e na sua posição original. As arquiteturas ncc-numa (non-cache coherent NUMA) não provêem esse suporte. Conforme a figura 2, existem dois outros tipos de arquitetura: COMA (cache only memory architecture) e NORMA (non-remote memory access). Em uma máquina COMA, todas as memórias locais estão estruturadas como memórias caches e possuem, por hardware, uma replicação de um bloco de cache em todos os nós. Por isso, essas arquiteturas são mais caras de se implementar que as NUMA e raramente são usadas. As arquiteturas NORMA, por sua vez, salientam o aspecto de cada processador ter uma memória própria não compartilhada com os demais. A leitura (ou escrita) de uma posição de memória de outro processador só é possível via troca de mensagens. Os clusters de computadores (agregados) seguem esse modelo. Este trabalho aborda as questões de programação em máquinas UMA e cc-numa, especialmente essas últimas. Por isso, nas próximas seções serão discutidos mais alguns aspectos destas duas classes de máquinas. O leitor interessado em obter mais detalhes sobre as outras classes pode consultar [16]. 2.1 Arquiteturas UMA As máquinas UMA são caracterizadas pelo fato de que a memória é centralizada e acessível por todos os processadores da mesma forma, isso faz com que a latência de acesso à memória seja idêntica para todos esses. A rede de interconexão (figura 3a) normalmente usada é o barramento, o que gera um gargalo de acesso já que só pode haver um processador por vez realizando acessos à memória. Essa característica limita o número de processadores a serem empregados em uma arquitetura UMA já que, quanto mais processadores houver, maior a chance de disputas de acesso ao barramento e o aumento do tempo de espera para acessá-lo. Entretanto, há formas de reduzir esse conflito de acesso como, por exemplo, o uso de outras redes de interconexão, o emprego de memórias multiportas, organização da memória em bancos, memórias cache etc. O importante, porém, é manter a latência de acesso à memória uniforme. Todos os processadores atuais possuem caches internas para dados e instruções organizadas em um sistema hierárquico (L1, L2 e L3). As memórias cache atuais chegam a vários megabytes dependendo do modelo do processador e de seu fabricante. As caches, além de melhorem o desempenho do sistema já que seu tempo de acesso é inferior que os das memórias RAM em pelo menos uma ordem de grandeza, contribuem para reduzir o gargalo do barramento. Apenas os acessos às posições de memória não mantidas em cache necessitam disputar o uso do barramento. Entretanto, o uso de cache introduz o problema

7 de coerência de cache: sempre que uma posição de memória for modificada, sua cópia mantida em qualquer cache deve ser invalidada para que o processador seja forçado a buscar o novo valor na memória RAM. A unidade de transferência de dados entre a memória RAM e a cache de um processador é um conjunto contíguo de bytes, denominado de linha de cache. Conseqüentemente, apesar de ser modificado apenas um valor, toda a linha da cache é invalidada. Os multiprocessadores simétricos (Symmetric MultiProcessors SMP), disponíveis comercialmente, são exemplos típicos de máquinas UMA. Nessas máquinas é comum encontrar uma rede de interconexão do tipo barramento. Esse barramento, além de possuir as vias de endereços, de dados e de controle implementa um arbitrador e um protocolo de coerência de cache. O arbitrador serve para coordenar o acesso de um processador à memória RAM através do barramento impedindo acessos simultâneos e conflituosos entre processadores. Sempre que um processador modificar um dado contido em uma linha de cache, cabe ao protocolo de coerência de cache propagar essa modificação até a memória RAM e invalidar toda e qualquer outra linha de cache incluindo outros processadores que mantém uma cópia dessa posição de memória modificada. Mais recentemente, os computadores de uso geral começaram a vir com processadores dualcore, ou mesmo quadcore. Basicamente, um processador multicore é uma arquitetura UMA, só que interna a um chip. As unidades de processamento (cores) compartilham o acesso à memória da mesma forma que os processadores em um SMP. Em alguns processadores, o compartilhamento de memória já inicia na própria cache, nos níveis L2 ou L3. O problema de coerência de cache aparece novamente, já que pelo menos o nível L1 é privativo de cada core e pode manter cópias de posições de memórias. 2.2 Arquiteturas NUMA As máquinas NUMA são construídas interconectando vários módulos compostos por processadores e memórias. Partindo dessa descrição é possível se perguntar qual a diferença entre uma máquina NUMA e um cluster de computadores, pois este último nada mais é do que um conjunto de computadores (processador e memória) interconectados por uma rede de comunicação. Existem duas grandes diferenças. Primeiro, em uma máquina NUMA existe um único sistema operacional gerenciando todos os recursos (memória, processadores e entrada/saída), em um cluster, cada nó (computador) é uma máquina independente com o seu próprio sistema operacional. Segundo, o espaço de endereçamento de uma máquina NUMA é único e compartilhado, isto é, as memórias dos diferentes módulos compõem a memória total do sistema, cada uma respondendo por uma faixa do endereçamento total. Em um cluster, cada máquina tem um espaço de endereçamento privativo. Além disso, a rede de interconexão de um cluster é normalmente uma rede de comunicação standard como, por exemplo, Ethernet, e em arquiteturas NUMA a rede de interconexão é normalmente uma solução proprietária baseada em diferentes técnicas de comutação. Como visto anteriormente, o N de NUMA vem do fato que o acesso à memória é não uniforme: acessos a posições de memória remotas possuem uma latência maior, isto é, são mais lentos, que acessos a posições de memória locais. Em uma máquina NUMA todos os processadores enxergam o mesmo espaço de endereçamento, porém algumas posições são mais demoradas de se acessar que outras.

8 Analisando apenas sob o ponto de vista de espaço de endereçamento, o paradigma de programação usado em multiprocessadores simétricos (SMP) funciona corretamente em máquinas NUMA, desde que estas mantenham coerência de cache. Entretanto, executar corretamente é diferente de executar eficientemente. Se por um lado, as máquinas NUMA tem a vantagem de agregar mais paralelismo real adicionando mais processadores sem aumentar o conflito e gargalo de acesso ao barramento, comuns aos SMP, ela apresenta a desvantagem de fornecer um acesso não-uniforme à memória. Esse acesso não uniforme é importante para o desempenho da aplicação e deve ser avaliado. Uma forma bastante comum de medir a não-uniformidade de acesso à memória é considerar a razão entre o acesso a uma posição de memória remota e um acesso a uma posição de memória local. Essa razão é também denominada de distância ou fator NUMA. Uma mesma máquina pode apresentar diferentes valores para o fator NUMA dependendo de qual processador acessa qual memória. Portanto, para uma aplicação executar de forma eficiente em uma arquitetura NUMA é desejável que os processos sejam escalonados nos processadores mais próximos possíveis da faixa de endereçamento que eles acessam para reduzir o fator NUMA. Fica claro que é necessário estimar o fator NUMA de alguma forma e o sistema operacional deve usar essa informação na sua decisão de escalonamento. A ACPI (Advanced Configuration and Power Interface) é uma especificação de um standard industrial aberto desenvolvido pela HP, Intel, Microsoft, Phoenix e Toshiba que define uma API (Application Program Interface) para obter informações sobre placas mães, reconhecimento de hardware, configurações de dispositivos e gerenciamento de energia [1]. A versão inicial da ACPI é de 1996 e, a versão 3.0, a atual, foi liberada em outubro de As informações fornecidas pela ACPI são organizadas de forma hierárquica em um conjunto de tabelas. Para máquinas NUMA, as tabelas mais relevantes são a SRAT (System Resource Affinity Table) e a SLIT (System Locality Information Table). A SRAT foi definida para ser usada em sistemas operacionais dedicados a máquinas NUMA para permitir que na tarefa de alocação de memória os dados sejam alocados o mais próximo, em latência de memória, do local onde o processo (ou thread) será executado. A SLIT, por sua vez, fornece a distância relativa (latência de memória) entre diferentes domínios ou localidades, isto é, processadores, controladores de memória e pontes. Cada nó que compõem uma máquina NUMA é equivalente a um SMP e recebe um valor de localidade arbitrado a 10. A SLIT pode ser vista como uma matriz de distâncias de dimensão n, onde n é a cardinalidade das localidades (número de nós) e a linha i fornece a distância da localidade i para uma localidade j qualquer. A diagonal dessa matriz é a distância de um nó a si mesmo, os demais valores são relativos a distância SMP (10). Por exemplo, se a distância da localidade i para a localidade j é 2.4 vezes maior que a distância SMP, o valor a ser posto nessa entrada da matriz é 24. A figura 4 fornece alguns exemplos de máquinas NUMA reais e suas respectivas SLITs. Infelizmente, apesar de ser um standard a ACPI ainda não é adequadamente implementada nas BIOS dos principais fabricantes. Pelo padrão, a tabela SLIT é opcional, mas, normalmente, é ela e não a SRAT que é encontrada na BIOS. Alguns sistemas operacionais, entre eles, o Linux e OpenSolaris, definem a distância entre módulos usando abstrações próprias como domínios e lgroup, respectivamente. Isso será apresentado nas seções 5.1 e 5.2.

9 Figura 4 Exemplos de arquiteturas NUMA e suas SLITs 3 Programação paralela Como visto na seção anterior, existem várias arquiteturas para máquinas paralelas, cada uma delas com uma determinada característica em relação à quantidade de fluxos de instruções e de dados que podem ser executados em um instante de tempo. O problema agora é como desenvolver programas para essas máquinas. As aplicações, em si, geralmente, apresentam paralelismo intrínseco que são mais apropriados para uma ou outra arquitetura de máquinas paralelas. Portanto, é necessário no desenvolvimento de aplicações paralelas adequar o tipo de paralelismo com uma classe de máquinas para obter o melhor desempenho possível. Além disso, é necessário expressar esse paralelismo de alguma forma. Surgem então as linguagens paralelas, compiladores para extração automática de paralelismo e modelos ou paradigmas de programação. Cada uma dessas técnicas apresenta vantagens e desvantagens, porém é mais comum encontrar o uso de paradigmas de programação.

10 Empregando os paradigmas de programação paralela é necessário que a aplicação a ser paralelizada seja dividida em várias subtarefas, cada uma delas consistindo em um fluxo de instruções e operando sobre um conjunto de dados. Esses paradigmas são naturalmente apropriados para a classe de máquinas MIMD. Entretanto, durante a execução das tarefas é bastante comum que as tarefas tenham necessidades de comunicar entre si para fornecer resultados parciais e esperar que uma, ou outra, atinja um determinado ponto de execução (sincronização). A forma como essa comunicação e a sincronização é obtida depende se a arquitetura apresenta memória distribuída ou compartilhada e para isso existem dois paradigmas de programação paralela: passagem de mensagens e memória compartilhada. 3.1 Paradigma de programação por passagem de mensagens O paradigma de passagem de mensagens é baseado em duas primitivas básicas, send e receive, através das quais as tarefas comunicam entre si fornecendo e recebendo valores uma das outras. Essas duas primitivas podem ser usadas para a sincronização das tarefas já que podemos imaginar que uma tarefa que executa um receive fica bloqueada esperando que os dados sejam enviados (send) por outra tarefa. Esse paradigma é coerente com as máquinas MIMD de memória distribuída, onde é possível imaginar que cada tarefa é um processo e, portanto, possui um espaço de endereçamento próprio e privativo. Um processo só consegue ler ou passar dados para o espaço de outro processo do recebimento ou envio explicito desses dados através de primitivas de passagem de mensagens. Essas primitivas são fornecidas por APIs implementadas por bibliotecas de comunicação como, por exemplo, MPI e PVM. O MPI apresenta um conjunto de mais de uma centena de primitivas para permitir diferentes padrões de troca de mensagens como comunicação ponto a ponto, em grupo, vários tipos de send e receive, bloqueantes e bloqueantes, com diferentes semânticas e primitivas de sincronização, entre outras. O MPI fornece ainda APIs para a linguagem de programação C e Fortran. O programador que desenvolve uma aplicação paralela baseada em passagem de mensagens, além de ter o conhecimento de como o paradigma deve ser usado, precisa estudar e conhecer as primitivas da biblioteca de comunicação para usá-la adequadamente. Note ainda que nesse paradigma a idéia é criar processos que se comunicam por trocas de mensagens independentes de estarem sendo executados fisicamente em uma mesma máquina ou em máquinas distintas. Por isso, passagem de mensagens e, em especial, o MPI, é largamente difundido entre aplicações executadas em clusters de computadores (classe MIMD fracamente acopladas do tipo NORMA). E o quê pode ser usado para desenvolver aplicações paralelas para as máquinas MIMD fortemente acopladas? Bom, inicialmente, é possível, apesar de não ser o mais adequado, usar passagem de mensagens, já que esse modelo é baseado na troca de mensagens entre processos independentemente de onde eles estão sendo executados. Entretanto, essa solução não é natural para as máquinas fortemente acopladas por duas razões. Primeira, os programadores devem saber desenvolver aplicações baseadas no paradigma de passagem de mensagens, o que exige um certo esforço de aprendizado e de programação. Segunda, como, por definição, os processos possuem espaços de endereçamento próprios e privativos, comunicar um valor de um processo A a um processo B implica em copiar esse valor do espaço de endereçamento de A para o espaço de endereçamento do B passando pelo núcleo do sistema operacional. Isto implica em cópias

11 e, conseqüentemente, em queda de desempenho. Já que uma máquina fortemente acoplada é caracterizada por possuir uma memória compartilhada por que não permitir que o processo A escreva diretamente no espaço de endereçamento do processo B? Isso dá origem ao paradigma de programação por memória compartilhada. 3.2 Paradigma de programação por memória compartilhada Assim como ocorre com o paradigma de troca de mensagens, existem APIs e implementações dedicadas a programação por memória compartilhada onde se destaca a programação orientada a threads (multithreading). Como mencionado anteriormente, um processo é uma abstração que representa um programa em execução e possui um espaço de endereçamento próprio onde estão o código a ser executado (text), as variáveis globais (data), uma área para alocação dinâmica de memória (heap) e uma pilha (stack), empregada em chamadas de procedimento e na definição de variáveis locais. O ponto da execução em que o processo se encontra, isto é, instrução a ser executada (program counter) e o estado da pilha (stack pointer) é determinado por um fluxo de execução (thread, em inglês). A idéia por trás do multithreading é permitir que um processo tenha mais de um fluxo de execução ao mesmo tempo (threads). A figura 5 ilustra esse conceito. Figura 5 O conceito de multithreading em processos UNIX

12 As threads compartilham o espaço de endereçamento de um processo, à exceção da área da pilha. Dessa forma, todas as threads enxergam o mesmo código, a área de memória correspondente as variáveis globais e área de heap, esta última empregada na alocação dinâmica de memória através de chamadas de sistemas do tipo malloc (memory allocation). Dessa forma, cada thread executa uma função do código, por exemplo, rotina1 e rotina2, como dado na figura 5 (na realidade, as threads também podem executar uma mesma função). A comunicação entre uma thread 1 e uma thread 2 ocorre de forma bastante natural, bastando que uma delas escreva diretamente em uma posição de memória e a outra leia esta posição como, por exemplo, na seguinte situação: a thread1 atribui um valor a uma posição do arraya (arraya[2]=10) e a thread2 lê esse valor (x=arraya[2]). A sincronização entre as threads é fornecida por primitivas como mutexes, semáforos e variáveis de condições. Cabe ressaltar que as threads são particularmente importantes quando há mais de uma unidade de processamento em uma máquina, já que o sistema operacional pode escalonar para execução uma thread em cada unidade de processamento. Isso acontece em máquinas SMP, em máquinas NUMA e em processadores multicore. O suporte a threads pode ser implementado em nível de usuário, através de uma biblioteca (runtime), ou no próprio sistema operacional. Hoje em dia, todos os sistemas operacionais oferecem suporte a threads no próprio núcleo. Para um programador explorar o uso de threads uma API é disponibilizada pelo próprio sistema operacional ou integradas em uma linguagem de programação como o Java. No mundo Unix, a API mais difundida é a POSIX threads (Pthreads). A principal vantagem da programação orientada a threads é permitir que os programadores empreguem um conceito mais natural e comum do que a passagem de mensagens. A exploração do paralelismo real fica a cargo do sistema operacional. É importante notar que nesse caso, o sistema operacional tem uma contribuição significativa no desempenho de uma aplicação baseada em threads. Essa importância será discutida nas próximas seções. 4 Gerência de memória em Unix Um processo Unix que executa em arquiteturas de 32 bits pode, teoricamente, ocupar até 4 Gbytes. Entretanto, o espaço em memória física (RAM) é um recurso escasso e o sistema operacional deve dividi-lo entre os vários processos em execução. Quando é necessário carregar um novo processo em memória, o sistema operacional traz do disco apenas as porções necessárias à sua execução e não o processo inteiro. Se ao executar, o processo acessa uma posição de memória que não está carregada em memória, o sistema operacional bloqueia esse processo, realiza a carga da porção que está faltando e, na seqüência, torna o processo novamente apto a executar. Esse esquema de gerenciamento de memória desvincula o tamanho lógico do processo do espaço disponível em RAM, já que o sistema operacional mantém em memória física apenas as porções necessárias à execução do programa. Isso é a base do que é denominado de memória virtual [18]. Existem duas técnicas fundamentais para definir as porções de memória: segmentação e paginação. Na segmentação, o espaço de endereçamento do processo é dividido em porções de tamanhos variáveis denominados de segmentos. Já na paginação,

13 essas porções possuem tamanhos fixos e são denominados de páginas. A maioria dos sistemas operacionais emprega paginação por seu gerenciamento ser mais simples. A paginação é uma técnica de gerenciamento de memória que consiste em dividir tanto o espaço de endereçamento lógico do processo quanto o espaço físico em memória RAM em porções de tamanho fixo denominadas de página e quadros (frames), respectivamente. O sistema operacional mantém uma lista de quadros livres e os aloca a páginas à medida que os processos vão sendo carregados em memória (paginação por demanda). Qualquer página pode ser alocada a qualquer quadro. A vinculação entre páginas e quadros é feita a partir de uma tabela de páginas. O leitor interessado em obter mais detalhes desse procedimento pode consultar [18][15]. 4.1 Alocação de memória Sempre que um processo é criado, é definido um espaço de endereçamento lógico que pode ser visto como uma espécie de ambiente de execução contendo código, dados e pilha. O procedimento de criação de processos em Unix é baseado nas chamadas de sistema fork e exec. Um processo, denominado de processo pai, quando executa a chamada de sistema fork cria um novo processo, atribuindo um novo pid (process identifier) e um espaço de endereçamento lógico, que é, à parte algumas estruturas de dados e informações internas de contabilidade do sistema operacional, uma cópia quase exata do seu próprio espaço de endereçamento [21]. Na prática, isso é feito com que o processo filho receba uma cópia da tabela de páginas do processo pai. Entretanto, na maioria das vezes o processo filho é criado para executar um código diferente do processo pai. Assim, na seqüência o processo filho executa a chamada de sistema exec para substituir as cópias das páginas do processo pai por páginas próprias provenientes de um arquivo executável. A partir desse ponto, os processos pai e filho, se diferenciam. Nesse ponto, ocorre uma alocação de memória para as páginas do processo filho. Os processos, uma vez em execução, podem alocar memória adicional a partir da área de heap de seu espaço de endereçamento lógico. Isso é feito adicionando novas páginas ao seu espaço de endereçamento virtual, ou seja, aumentando o número de entradas em sua tabela de páginas, através da chamada de sistema malloc. Entretanto, normalmente, no Unix, a vinculação de uma nova página (endereço lógico) a um quadro (memória real) só acontece quando essa página for acessada pela primeira vez. Essa política é conhecida como first touch [21]. Posto de outra forma, ao se realizar uma primitiva malloc se obtém um espaço de endereçamento lógico proporcional à quantidade solicitada por malloc, porém a memória física correspondente só será realmente alocada quando for feito o primeiro acesso a ela. 4.2 O problema do falso compartilhamento A leitura e a escrita de dados na memória RAM envolve a geração de sinais de controle e o acesso ao barramento de dados e de endereço, que é normalmente compartilhado com outros subsistemas, como E/S, e, em máquinas multiprocessadores, com outros processadores. Além disso, há o próprio tempo de leitura e escrita na memória RAM. Para diminuir esse tempo (latência) todos os processadores atuais possuem um ou mais níveis de cache, já que as caches são internas ao processador e a memória RAM é externa. O princípio básico da cache é copiar um bloco de dados da memória principal para

14 uma linha de cache e assim permitir que a unidade de processamento acesse os dados sem realizar um acesso a RAM. Essa técnica funciona bem em sistemas monoprocessados executando programas seqüenciais, porém em máquinas SMP, ou em programas concorrentes usando multithreading, alguns cuidados devem ser tomados para não se comprometer o desempenho da aplicação. O falso compartilhamento (false sharing) ocorre quando múltiplos processadores compartilham uma mesma linha de cache sem efetivamente compartilharem os dados nela contidos [20]. Os algoritmos de alocação de memória em máquinas SMP podem provocar o falso compartilhamento alocando objetos (variáveis) consecutivamente em memória e, posteriormente, passando-os como parâmetros a threads independentes que serão executadas em diferentes processadores. Dessa forma, como ilustrado na figura 6, qualquer thread, em qualquer processador, que modificasse seu próprio objeto (variável) estaria invalidando a cache dos demais processadores por ter modificado a mesma linha de cache, embora não os dados utilizados por eles. Uma forma de resolver esse problema seria fazer com que o algoritmo de alocação de memória reservasse para cada objeto (variável) uma linha de cache, porém isso levaria a um grande desperdício de memória. Por exemplo, em processadores Sparc, a linha de cache é 64 bytes, se cada objeto fosse um inteiro (4 bytes) e ocupasse uma linha, cada um deles desperdiçaria 60 bytes na memória e, pior, na cache também. Convém salientar que esse problema ocorre mesmo quando há um único processador, pois uma thread ao modificar sua porção na linha de cache estaria invalidando toda ela. Figura 6 O problema do falso compartilhamento

15 O problema do falso compartilhamento também pode ocorrer quando diferentes threads executam a primitiva malloc e esta satisfaz as requisições de memória alocando espaço que é mapeado em uma mesma linha de cache (figura 7). Por exemplo, o algoritmo de alocação pode dividir um bloco de dados, mapeado em uma linha de cache entre x threads. Se uma delas realizasse uma escrita, a linha da cache seria invalidada e qualquer uma das outras x-1 threads que executasse uma operação de leitura deveria recarregar o bloco de dados para a cache. Figura 7 O problema do falso compartilhamento (outra situação) A conclusão que se tem é que os algoritmos de alocação de memória, principalmente em máquinas SMP, devem, na medida do possível, evitar o problema do falso compartilhamento. O Hoard [2] é uma proposta de alocador de memória para máquinas SMP executando Linux que busca reduzir o falso compartilhamento e ao mesmo tempo fazer um uso eficiente de memória. A técnica empregada consiste em dividir a área de heap entre os vários processadores do sistema e em uma área global compartilhada entre eles. O princípio básico é fazer com que uma thread, executando uma primitiva malloc em um processador i, tenha sua requisição de memória atendida por uma área de memória exclusiva àquele processador e assim evite a situação de uma área contígua ser alocada a diferentes threads em diferentes processadores. 5 Suporte do sistema operacional para NUMA Na seção 4 foram discutidos alguns aspectos sobre a gerência de memória em sistemas Unix em geral. Dessa discussão parece ficar claro que o sistema operacional tem uma forte influência no desempenho na execução de uma aplicação. A prova está na preocupação de sistemas operacionais para arquiteturas convencionais, como o Windows, em introduzir o conceito de afinidade no escalonamento de threads [17]e na proposta de um novo alocador de memória (Hoard) para o Linux. No caso específico de arquiteturas NUMA a preocupação está em fazer com que uma thread realize os acessos na memória local ao nó que ela executa. Essa lógica, aparentemente simples, possui uma série de pontos a serem considerados. Por exemplo, o que acontece se após alocar a memória fisicamente em um nó, a thread é escalonada para executar em outro processador? Ou, o que ocorre se não há memória suficiente no nó em

16 que a thread está executando? As respostas a essas e outras questões se traduzem em considerar a característica NUMA nas tarefas de escalonamento e gerenciamento de memória. Da mesma forma, é importante que o usuário tenha um conhecimento do que está acontecendo na máquina e que ele tenha mecanismos de influenciar e auxiliar as decisões do sistema operacional quanto ao escalonamento e a gerência de memória. Normalmente, isso é disponibilizado por bibliotecas de comunicação e por comandos específicos as máquinas NUMA. O principal conceito por trás de sistemas operacionais voltados a máquinas NUMA é o de afinidade. A idéia é fazer com que uma thread seja vinculada a um processador e que suas demandas por memória sejam satisfeitas de forma a oferecer o menor tempo de acesso possível. Fala-se em afinidade de processador e afinidade de memória. Esses conceitos podem ser implementados de diferentes maneiras e a melhor maneira de entendê-las é analisar como fazem os sistemas operacionais NUMA compatíveis. Este é o principal objetivo desta seção e para atingi-lo serão estudadas as implementações dos sistemas operacionais GNU/Linux e OpenSolaris. 5.1 Linux em arquiteturas NUMA O suporte a multiprocessadores em geral começou a ser introduzido no Linux a partir da versão 2.6 do núcleo através de modificações nos subsistemas responsáveis pelo escalonamento e pela gerência de memória. Além disso, para explorar adequadamente as características NUMA, foram introduzidas novas estruturas de dados para manter informações sobre a topologia da máquina, novas chamadas de sistemas e uma API em nível de usuário. A modificação mais importante no núcleo talvez tenha sido a introdução do conceito de domínio de escalonamento, sobre o qual o escalonador se baseia para tomar decisões. Isso afeta qualquer tipo de multiprocessador, incluindo as máquinas NUMA. Depois, o subsistema de memória virtual, que foi alterado para considerar a topologia de uma máquina NUMA quanto à localização física da memória para as tarefas de alocação e liberação de memória. Em particular, foram introduzidas políticas que permitem o usuário informar ao sistema como (e onde) a memória deve ser alocada. Além disso, a SGI introduziu em sua versão de Linux uma abordagem interessante, que é a replicação nos diferentes nós de uma máquina de áreas de memória read-only, como o código do próprio núcleo e de bibliotecas como a libc [3]. Isso reduz o tráfego entre os nós e a latência de acesso ao código do núcleo, já que todos os acesso serão feitos em uma cópia local. As novas chamadas de sistema, entre outras, permitem configurar uma política de gerência de memória para uma determina faixa de endereçamento (mbind), para um processo específico (set_mempolicy) e vincular um processo a um determinado processador (sched_setaffinity). Para o usuário essas funcionalidades são disponibilizadas através de uma API da biblioteca libnuma. Há também a possibilidade de configurar as políticas de memória e afinidade por linha de comando via numactl. Nas próximas seções, essas novidades serão apresentadas de forma mais detalhada.

17 5.1.1 Domínios de escalonamento Nas versões do núcleo anteriores a 2.6, o escalonador do Linux organizava todos os processos aptos a executar em uma única fila. Quando o processador se tornava livre, o algoritmo de escalonamento selecionava um processo dessa lista e o colocava em execução. Esse procedimento era simples e eficiente para máquinas com um único processador. Na medida que mais processadores foram sendo introduzidos no sistema via multithreading ou multicore essa fila começou a se tornar um gargalo de acesso. A solução adotada foi criar múltiplas filas, uma por processador. No entanto, essa solução trouxe consigo o problema de balanceamento de carga, ou seja, como distribuir de forma eqüitativa os processos (ou threads) entre os vários processadores. O Linux aborda o problema do balanceamento de carga com o auxílio da abstração de domínios de escalonamento (sched domains) para construir uma estrutura hierárquica em árvore que representa a topologia da máquina [11]. Essencialmente, um domínio de escalonamento é uma estrutura de dados (sched_domain) que implementa uma lista circular de outras estruturas (sched_groups) as quais definem os processadores que compõem um determinado domínio. Por exemplo, em processadores SMT, cada processador é representado por um sched_group diferente. Nesse caso, um sistema com dois processadores dualcore é visto pelo núcleo como dois domínios diferentes, um por processador, e cada um deles com dois sched_group (um por core). Um outro exemplo, uma máquina cc-numa com quatro processadores, dois em cada nó, é vista como na figura 8. Nesse último caso aparece a noção de hierarquia, cada nó define um domínio de escalonamento (folhas) formado por dois processadores e há um domínio de escalonamento formado pelos quatro processadores. Figura 8 Exemplo de domínios de escalonamento. O algoritmo de balanceamento de carga tenta manter todos os processadores com uma carga similar, porém isso é feito no interior de um domínio. Isso implica em migrar processos do processador mais ocupado a um processador menos ocupado dentro de um mesmo domínio-folha. O objetivo de evitar migração entre processos de domínios diferentes é mantê-los próximo à memória que eles acessam, porém, a migração interdomínios pode ocorrer. Nesse ponto, o Linux possui uma deficiência: os processadores de diferentes nós são agrupados em um domínio de hierarquia superior sem considerar seus

18 fatores NUMA eventualmente diferentes. Por exemplo, na figura 8, os processadores 0 a 3 são considerados de forma idêntica, independentemente de seus fatores NUMA individuais. A conseqüência disso é a possibilidade de migrar processos para processadores com o maior fator. Uma proposta de algoritmo de balanceamento de carga que considera os diferentes fatores NUMA é dado em [22]. As várias funcionalidade e comportamento do algoritmo original de balanceamento de carga do Linux podem ser vistas em [3] e [12 ] Gerenciamento de memória O sistema de gerenciamento de memória é baseado em uma entidade central denominada de alocador de páginas que trata as requisições de memória feitas pelos diferentes subsistemas do núcleo. O ponto a destacar é que o alocador atende essas requisições trabalhando sobre um conjunto de páginas que são mapeadas, posteriormente, para memória física. A vinculação de páginas a memória física (quadros) pode ser otimizado para latência ou para banda passante. Sempre que um processador acessa a memória local a seu nó, temos a menor latência. Entretanto, algumas aplicações podem ser mais sensíveis a banda passante de memória. Nesse caso, já que cada nó possui seus próprios controladores de memória é possível fazer com que eles trabalhem em paralelo de forma similar ao que acontece em um sistema RAID. A idéia é dividir o espaço de endereçamento do processo em blocos através de todo o sistema de memória. As diferentes porções podem ser acessadas em paralelo. Apesar dessa possibilidade, é mais comum que as aplicações procurem reduzir a latência. A maneira pela qual a memória será alocada no espaço de endereçamento físico é definida por uma série de políticas. Essas políticas são disponibilizadas para o usuário através da API NUMA. O Linux prevê quatro políticas básicas: Default: aloca memória no nó onde o processo (thread) está executando. Strict: a memória é alocada em um nó específico. Se não houver memória disponível, a requisição por memória retorna com erro. Na API NUMA, esse corresponde ao modo bind da API NUMA. Non-strict preferred: a alocação é feita preferencialmente em um determinado nodo, se ela não pode ser atendida, o sistema recai para o caso default. Esse modo é denominado de preferred na API NUMA. Round-robin: a memória é distribuída igualmente em todos os nós, na API NUMA isso equivale ao modo denominado de interleaved. Essas políticas podem ser definidas globalmente para o sistema, por uma região do espaço de endereçamento físico, ou por processo. Cabe ressaltar que a memória física só é efetivamente alocada e vinculada a uma página lógica quando do seu primeiro acesso, em outros termos, o Linux executa first-touch.

19 5.1.3 As chamadas de sistema da API NUMA O suporte NUMA adiciona três novas chamadas de sistema que afetam a alocação de memória: mbind, set_mempolicy e get_mempolicy. A chamada mbind permite definir uma política para uma região de memória, set_mempolicy é usada para definir a política a ser empregada pelo processo (thread) que a executa e, por fim, get_mempolicy que permite se consultar a política atual de quem realiza a chamada. Entretanto, as aplicações não utilizam diretamente essas chamadas de sistema, mas sim a API fornecida pela biblioteca libnuma ou via o comando numactl. Essas novas chamadas não fazem parte da glibc e uma aplicação que deseja empregá-las diretamente deve ser ligada com libnuma O comando numactl Em máquinas que executam o Linux com suporte a máquinas NUMA é disponibilizado o comando numactl que permite aplicar políticas NUMA para a execução de um determinado processo. Isso é interessante principalmente para os casos onde o usuário não tem acesso ao fonte da aplicação para modificá-lo e introduzir chamadas de sistemas ou funções da libnuma. Entre as opções disponibilizadas por numactl está a possibilidade de definir a política de alocação de memória para o processo, em quais nós o processo deve ser executado e para obter uma série de informações de configurações sobre o hardware da máquina. Várias dessas opções recebem como parâmetro uma máscara (nodemask) que diz para qual nó uma determinada política se aplica. Cada nó do sistema tem uma identificação única. É importante salientar que nó é diferente de processador, ou seja, por exemplo, indicar que um processo executa no nó 1, implica que ele pode executar em qualquer processador que pertença ao nó A biblioteca libnuma A desvantagem do comando numatcl é que ele afeta a execução de todo o processo, isto é, seus processos e ou threads. Às vezes é necessário ter uma granularidade menor, esse é o objetivo da libnuma. A libnuma é uma API que permite ao usuário, através de uma programação, definir políticas NUMA individualmente por threads. É importante salientar esse aspecto, a política é válida apenas para a thread que executa a função libnuma não afetando as demais. A libnuma disponibiliza cerca de vinte e cinco funções diferentes que servem para vários propósitos. Através delas é possível consultar informações sobre a máquina e sobre o sistema operacional, como por exemplo, o número de nós, a quantidade de processadores por nó, o tipo de política empregada e mesmo se o sistema oferece ou não o suporte NUMA, entre outras. Além disso, é possível definir políticas de memória por nó, por thread e por processo e determinar em qual nó uma determinada thread deverá executar. Várias dessas chamadas recebem como argumento uma máscara (nodemask) que é um mapa de bits dos nós do sistema NUMA.

20 5.2 OpenSolaris em máquinas NUMA O OpenSolaris é um sistema operacional de código aberto baseado no núcleo do Solaris, um sistema Unix-like, desenvolvido pela Sun Microsystems. A principal diferença entre o Solaris e o OpenSolaris é que este último não é uma distribuição completa de sistema operacional. Ele possuí apenas o código do núcleo, algumas bibliotecas de programação e comandos Unix, mas a medida que o projeto OpenSolaris evolui mais funcionalidades vão sendo incluídas. Atualmente, existem três principais distribuições: Solaris Express Developer Edition, Nexenta OS e BeleniX. Apesar da Sun não fazer uma distribuição própria, na prática o Solaris Express é considerado uma. O Solaris express é composto pela versão mais recente do núcleo OpenSolaris e permite ao usuário escolher um, dentre dois, sistemas de janelas, Gnome e CDE (Commom Desktop Environment). O Nexenta OS é composto por software GNU executando sobre o núcleo OpenSolaris e emprega o Gnome como sistema de janelas e um gerenciador de pacotes baseado no Synaptic. Por fim, o BeleniX, desenvolvido em Bagalore (India), que executa na forma de um CD-live. O ponto importante a salientar é que, atualmente, o código do núcleo do Solaris e do OpenSolaris é o mesmo. Eles têm exatamente a mesma funcionalidade, incluindo o suporte para máquinas NUMA, portanto, no contexto deste trabalho, eles são equivalentes. O OpenSolaris provê suporte para arquiteturas NUMA através de um framework denominado de Memory Placement Optmization (MPO) construído em torno de três conceitos: localidade, balanceamento de carga e suporte dinâmico a topologia. O conceito de localidade implica que o núcleo conhece quais recursos físicos, memória, processadores e outros dispositivos, estão instalados em cada módulo (nó) e usa essa informação para obter o melhor desempenho da máquina. A idéia é alocar os recursos próximos ao nó onde a aplicação está executando. Para implementar isso, o núcleo mantém estruturas de dados que criam grupos de recursos de hardware em função da sua proximidade. Esses grupos são denominados de grupos de latência, ou simplesmente, lgroups. A razão de alocar recursos próximos a aplicação é minimizar o número de acessos remotos reduzindo tempo de latência [14]. Embora a localidade seja importante, e extremamente relevante, o sistema operacional busca também efetuar um balanceamento de carga para evitar que recursos fiquem ociosos. Se o sistema operacional levar à risca o critério de proximidade, é possível que alguns nós fiquem sobrecarregados enquanto outros estarão ociosos. O núcleo do OpenSolaris, em suas decisões, tenta escalonar threads em diferentes nós mantendo uma relação custo versus benefício entre localidade e carga. Por fim, o núcleo mantém informações sobre a topologia da máquina permitindo que dispositivos sejam inseridos e removidos à quente. A nova topologia é reconhecida e os valores de latência (localidade) são reavaliados. Apesar de todos os três conceitos serem fundamentais, o mais importante é o de grupos de latência, pois dele tudo se deriva.