melhorando o desempenho de sistemas de …...para o modelo de memória compartilhada é mais natural...
TRANSCRIPT
UNIVERSIDADE FEDERAL DO RIO GRANDE DO SULINSTITUTO DE INFORMÁTICA
PROGRAMA DE PÓS-GRADUAÇÃO EM COMPUTAÇÃO
Melhorando o Desempenho de Sistemas deMemór ia Compartilhada Distr ibuída –
Abordagens e Técnicas
porEDVAR BERGMANN ARAUJO
Trabalho Individual II
Prof. Dr. Cláudio Fernando Resin GeyerOrientador
Porto Alegre, janeiro de 2000
2
CIP – CATALOGAÇÃO NA PUBLICAÇÃO
Araujo, Edvar BergmannMelhorando o Desempenho de Sistemas de Memória
Compartilhada Distribuída – Abordagens e Técnicas / por EdvarBergmann Araujo – Porto Alegre: PPGC da UFRGS, 2000.
71f.:il .
Trabalho orientado pelo Prof. Cláudio Fernando Resin Geyer.
1. Memória compartilhada distribuída. 2. Sistemas distribuídos.I. Geyer, Cláudio Fernando Resin. II. Título.
UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
Reitora: Profa. Wrana Panizzi
Pró-Reitor de Pós-graduação: Prof. Franz Rainer Semmelmann
Diretor do instituto de Informática: Prof. Phili ppe Olivier Alexandre Navaux
Coordenadora do PPGC: Profa. Carla Freitas
Bibliotecária-Chefe do Instituto de Informática: Beatriz Haro
3
Lista de Abreviaturas
CPU Central Processing Unit
CVM Coherent Virtual Machine
D-CVM Dynamic Coherent Virtual Machine
DSM Distributed Shared Memory
LRC Lazy Release Consistency
NOW Network of Workstations
PC Pernonal Computer
RAHM Remote Access Historiy Mechanism
RSD Regular Section Descriptor
VPM Virtual Parallel Machine
4
Sumár io
Lista de Abreviaturas___________________________________________________3
Lista de Figuras _______________________________________________________6
Lista de Tabelas _______________________________________________________7
Resumo ______________________________________________________________8
Abstract______________________________________________________________9
1 Introdução_________________________________________________________10
1.1 Tema__________________________________________________________10
1.2 Motivação______________________________________________________10
1.3 Objetivos ______________________________________________________11
1.4 Estrutura do Texto ______________________________________________12
2 Suporte de Compilação_______________________________________________13
2.1 Suporte de Compilação para o TreadMarks _________________________132.1.1 Introdução___________________________________________________132.1.2 Compilador e Ambiente de Execução _____________________________142.1.3 Análise de Compilação_________________________________________152.1.4 Ambiente de Execução Incrementado _____________________________15
2.2 Suporte de Compilação para o CVM _______________________________172.2.1 Introdução___________________________________________________172.2.2 Compilador e Ambiente de Execução _____________________________182.2.3 Interface Compilador / Software DSM ____________________________192.2.4 Reduzindo o Overhead de Sincronização___________________________20
2.3 Comparação____________________________________________________22
3 Técnicas para Evitar Falso Compartilhamento____________________________23
3.1 Efeitos do Falso Compar tilhamento ________________________________23
3.2 Agregação de Páginas____________________________________________243.2.1 Introdução___________________________________________________243.2.2 Agregação Dinâmica __________________________________________24
3.3 Adaptable View _________________________________________________253.3.1 Introdução___________________________________________________253.3.2 MultiView __________________________________________________263.3.3 Várias Granularidades de Compartilhamento _______________________27
3.4 Comparação____________________________________________________30
4 Escalonamento de Threads____________________________________________31
4.1 Introdução _____________________________________________________31
4.2 RAHM ________________________________________________________324.2.1 O Mecanismo________________________________________________324.2.2 Escalonamento de Threads______________________________________33
5
4.2.3 Tratamento de Ping-Pong_______________________________________37
4.3 Corre lation Tracking ____________________________________________394.3.1 Ambiente de Execução_________________________________________394.3.2 Paralelismo e Balanceamento de Carga____________________________404.3.3 Correlação entre Threads_______________________________________414.3.4 Mecanismos de Identificação de Correlações _______________________424.3.5 Heurísticas de Mapeamento de Threads ___________________________45
4.4 Comparação____________________________________________________46
5 Técnicas de Tolerância à Latência______________________________________47
5.1 Introdução _____________________________________________________47
5.2 Multi threading __________________________________________________485.2.1 Introdução___________________________________________________485.2.2 Modelo de Programação________________________________________495.2.3 Implementação_______________________________________________49
5.3 Combinação de Prefetching e Multithreading ________________________505.3.1 Prefetching __________________________________________________505.3.2 Multithreading _______________________________________________525.3.3 Combinando Prefetching e Multithreading _________________________52
5.4 Comparação____________________________________________________53
6 Ferramentas de Visualização __________________________________________55
6.1 Introdução _____________________________________________________55
6.2 PAPP__________________________________________________________566.2.1 Interface do Usuário___________________________________________566.2.2 Coleta dos Dados _____________________________________________58
6.3 Carnival _______________________________________________________596.3.1 A Ferramenta ________________________________________________596.3.2 Análise do Tempo em Espera____________________________________606.3.3 Análise da Comunicação _______________________________________616.3.4 Visualização de Desempenho com Carnival ________________________63
6.4 Comparação____________________________________________________64
7 Conclusão _________________________________________________________66
Bibliografia__________________________________________________________68
6
Lista de Figuras
FIGURA 2.1 – Modelo de programação____________________________________14
FIGURA 2.2 – Modelo de paralelização SUIF/CVM __________________________17
FIGURA 2.3 – Otimizações identifi cadas pelo compilador _____________________20
FIGURA 3.1 – Várias visões_____________________________________________26
FIGURA 3.2 – Vários níveis de compartilhamento ___________________________28
FIGURA 4.1 – Efeito ping-pong__________________________________________38
FIGURA 4.2 – Curva de speedup_________________________________________40
FIGURA 4.3 – Cálculo da quantidade de trabalho ___________________________41
FIGURA 4.4 – Bits de correlação por página _______________________________44
FIGURA 4.5 – Bitmap de acesso por thread ________________________________44
FIGURA 5.1 – Diferentes overheads de uma requisição remota _________________48
FIGURA 6.1 – Janela de Visualização da PAPP_____________________________57
FIGURA 6.2 – Legenda de cores da PAPP _________________________________ 57
FIGURA 6.3 – Análise de um intervalo específico____________________________58
FIGURA 6.4 – Janela de visualização do Carnival ___________________________63
7
Lista de Tabelas
TABELA 6.1 – Overheads identifi cados ____________________________________59
8
Resumo
Este trabalho apresenta um estudo comparativo de técnicas que podem serutili zadas para melhorar o desempenho de sistemas de memória compartilhadadistribuída (DSM). Os sistemas DSM permitem a integração da escalabili dade dasarquiteturas de memória distribuída com a maior facili dade de programação doparadigma de memória compartilhada. No entanto, o desempenho alcançado pelossistemas DSM é normalmente menor do que o alcançado com bibliotecas de troca demensagens.
O objetivo central deste trabalho é apresentar técnicas que procuramaproximar o desempenho alcançado pelos sistemas DSM ao das bibliotecas de troca demensagens. A utili zação de um suporte de compilação procura melhorar o desempenhoatravés da inclusão no código fonte de primitivas que informam antecipadamente aoambiente de execução sobre ações futuras. As técnicas que baseiam-se na mudançadinâmica do tamanho da unidade de coerência de acordo com o comportamento dosdados compartilhados almeja evitar o falso compartilhamento. O escalonamento dethreads preocupa-se com a distribuição de threads para nodos buscando a localidadedos acessos à memória. Técnicas de tolerância à latência, como prefetching emultithreading, tentam reduzir o tempo que o processador fica sem trabalho útil arealizar. As ferramentas de visualização permitem ao programador observar ocomportamento da execução, identificando os pontos onde existem anomalias.
Palavras-chave: memória compartilhada distribuída, sistemas distribuídos.
9
Abstract
This work presents a comparative study of techniques that can be used toimprove the performance of distributed shared memory systems (DSM). DSM systemsallows the integration of distributed memory architectures scalabili ty with largestfaciliti es of shared memory programming paradigm. However, the performance reachedby the DSM systems is usually smaller than reached with message passing libraries.
This work main goal is to present techniques that close the performance ofDSM systems with the performance of message passing libraries. The use of acompilation support tries to improve the performance adding calls in the source codethat inform to run-time about future actions. The techniques based on the dynamicresizing of the coherence unit in agreement with the behavior of the shared data mayavoid false sharing. The thread scheduling worries about distributing threads to nodeslooking for the locali ty of the memory accesses. Latency tolerance techniques, asprefetching and multithreading, try to reduce the time in which the processor is withoutuseful work to accomplish. The visualization tools allow the programmer to observe theexecution behavior, identifying the points where anomalies exist.
Keywords: distributed shared memory, distributed systems
10
1 Introdução
1.1 Tema
O tema deste trabalho é o estudo de técnicas que procuram melhorar odesempenho de sistemas de Memória Compartilhada Distribuída (DSM – DistributedShared Memory).
1.2 Motivação
Nos últimos anos tem crescido o interesse por sistemas de memóriacompartilhada distribuída. Estes sistemas permitem a integração da escalabili dade dasarquiteturas de memória distribuída com a maior facili dade de programação doparadigma de memória compartilhada.
Um sistema DSM oferece a abstração de um espaço de endereçamentológico, a que todos os processadores de uma arquitetura distribuída têm acesso, apesarde, fisicamente, a memória ser local a cada um deles. Implementado tanto em softwarecomo em hardware, os sistemas DSM controlam a distribuição física dos dados,oferecendo ao programador acesso transparente à memória virtual compartilhada.Portanto, o objetivo principal dos mecanismos de DSM é ocultar a comunicação doprogramador e fornecer um modelo de programação baseado em dados compartilhadosao invés de troca de mensagens. Além disso, aproveitam a escalabili dade e a relaçãocusto/eficiência inerentes aos sistemas de memória distribuída.
No que diz respeito ao software paralelo, em geral, o programador devepreocupar-se em estabelecer a interação entre os processos paralelos. Os dois principaisparadigmas de programação paralela são troca de mensagens e memóriacompartilhada. A programação no paradigma de memória compartilhada é consideradamais simples, pois evita que o programador preocupe-se com a comunicação entreprocessos, através de troca explícita de mensagens. No paradigma de troca demensagens a comunicação é realizada através de primitivas que explicitamentecontrolam o particionamento e o deslocamento dos dados.
Os sistemas DSM permitem que aplicações desenvolvidas para arquiteturasde memória compartilhada possam ser modificadas de forma relativamente fácil paraexecutarem em memória distribuída. Além disso, a conversão de aplicações seqüenciaispara o modelo de memória compartilhada é mais natural do que o seu desenvolvimentocom troca de mensagens. No entanto, o desempenho alcançado por estas aplicações emsistemas DSM normalmente é menor do que o desempenho alcançado com bibliotecasde troca de mensagens. Isso deve-se principalmente ao overhead adicionado pelosistema DSM para localizar e buscar os dados e para manter a consistência entre eles.
A característica dos sistemas DSM de fornecer uma interface transparente eum ambiente de programação conveniente para aplicações paralelas e distribuídas temfeito o assunto foco de numerosas pesquisas nos últimos anos. Atualmente, as pesquisasrealizadas nesta área estão voltadas para o desenvolvimento de técnicas que minimizemo tempo de acesso aos dados compartilhados e os overheads gerados pelo ambiente de
11
execução. Neste trabalho são abordados vários mecanismos que têm sido desenvolvidospara superar a diferença de desempenho entre as aplicações que executam em sistemasDSM e com bibliotecas de troca de mensagens, sem exigir muito envolvimento doprogramador.
Os sistemas DSM implementam a abstração da memória compartilhadaatravés do ambiente de execução. Com o auxílio de técnicas de análise estática, pode serpossível identificar o comportamento de parte dos acessos à memória. O código fonteda aplicação pode ser alterado com diretivas que informem ao ambiente de execuçãosobre o comportamento futuro dos acessos à memória, evitando assim que os dadossejam buscados sob-demanda.
O problema de falso compartilhamento [ARA 99] e [PRO 98] causacomunicação desnecessária. A comunicação em sistemas fracamente acoplados é umaquestão crítica. Esse problema pode ser reduzido se for possível adaptar dinamicamenteo tamanho da unidade de coerência (normalmente a página da memória virtual) àsnecessidades da aplicação.
O escalonamento de threads em sistemas DSM tem um desafio adicional, ode procurar manter a localidade das threads em relação à distribuição das páginas damemória compartilhada pelas memórias locais. Para isso deve ser considerado ocomportamento dos acessos as páginas de memória pelas threads. O escalonador devedecidir por alocar no mesmo processador threads que acessem o mesmo conjunto dedados, diminuindo assim o número de falhas remotas de página.
No momento que requisições remotas são realizadas, o processador querealizou a requisição fica sem trabalho útil a realizar. As técnicas de tolerância alatência procuram fazer com que o processador fique ocupado durante o tempo no quala requisição é resolvida.
Entender o desempenho de uma aplicação que executa em uma arquiteturadistribuída é uma tarefa árdua. Existem muitas variáveis dinâmicas que podem levar aum determinado comportamento. As ferramentas de visualização propõem-se a fornecermeios para que o programador possa entender o desempenho que suas aplicações DSMobtiveram.
1.3 Objetivos
O objetivo geral deste trabalho consiste no estudo de técnicas quemelhorem o desempenho de sistemas DSM.
Como objetivos específicos podem ser destacados:
1 – Estudar propostas de suporte de compilação;
2 – Estudar propostas que adaptem dinamicamente a granularidade daunidade de coerência às necessidades da aplicação;
3 – Estudar escalonamento de threads;
4 – Estudar técnicas de tolerância à latência;
5 – Estudar ferramentas de visualização;
6 – Comparar as características das técnicas estudadas;
12
7 – Criar um texto com os resultados do trabalho.
1.4 Estrutura do Texto
O capítulo dois aborda mecanismos de suporte a compilação. No capítulotrês são apresentadas técnicas que adaptam a granularidade da unidade de coerência àsnecessidades da aplicação. O capítulo quatro trata de questões relativas aoescalonamento de threads. No capítulo cinco são estudos mecanismos de prefetching emultithreading para tolerar a latência de memória e a latência de sincronização. Ocapítulo seis discorre sobre ferramentas de visualização. Finalmente, o capítulo seteconclui o trabalho.
13
2 Supor te de Compilação
Realizando uma análise estática do código fonte de uma aplicação pode serpossível determinar o comportamento dos acessos à memória compartilhada. Oambiente de execução aproveita as modificações geradas pelo compilador para realizarotimizações visando um melhor desempenho. A seção 2.1 apresenta uma proposta deintegrar um suporte de compilação para o sistema TreadMarks. Na seção 2.2 é abordadoo suporte de compilação para o sistema CVM. A seção 2.3 compara as propostasapresentadas.
2.1 Supor te de Compilação para o TreadMarks
O objetivo da proposta de Dwarkadas et al. [DWA 96] e [DWA 99] édesenvolver um sistema DSM que forneça ao usuário um modelo de programaçãobaseado em memória compartilhada, mas que seja capaz de explorar as característicasdo hardware que funciona com troca de mensagens.
2.1.1 Introdução
Nos sistemas DSM os acessos à memória compartilhada são detectadosdinamicamente pelo ambiente de execução, que envia mensagens de acordo com omodelo de consistência de memória implementado. Os compiladores paralelos paramáquinas de memória distribuída realizam uma análise estática do padrão de acessos àmemória compartilhada para gerar um programa com troca de mensagens. Sistemasbaseados em compilação oferecem melhor desempenho para programas com padrãoregular de acessos, pois evitam muito do overhead ocasionado pelo ambiente deexecução. Entretanto, não são todos os tipos de aplicações que permitem que umaanálise precisa seja realizada pelo compilador [DWA 99].
Por isso, a proposta de integrar um suporte de compilação a um sistemaDSM. Nos sistemas que utili zam o ambiente de execução combinado com ocompilador, o ambiente de execução mantém sua função original de detectar os acessosà memória compartilhada e enviar mensagens, se necessário, para manter a consistência.O compilador, no entanto, tem uma função diferente da que possui em um sistemabaseado em compilação. Quando a análise obtém sucesso o compilador não gera umprograma com troca de mensagens. Ao invés disso, gera um programa de memóriacompartilhada acrescido de chamadas para o ambiente de execução, que descrevem opadrão de acessos aos dados calculados pelo compilador. As informações sobre ocomportamento futuro dos acessos à memória evitam assim a necessidade do ambientede execução detectar os acessos à memória e buscá-los sob-demanda. Além disso,permitem a agregação de várias requisições de dados em uma única troca de mensagem.
Um aspecto interessante desse sistema combinado é suportar eficientementeprogramas com acessos regulares, com acessos regulares e irregulares e somente comacessos irregulares. Se os acessos são completamente regulares, o compilador podeanalisá-los e o código resultante é tão eficiente quanto código gerado pelo programadorou por compiladores para troca de mensagens [DWA 99]. Se a análise estática nãoobtém sucesso, o programa não é modificado, sendo executado pelo ambiente de
14
execução sem o suporte de compilação. Se a análise de compilação obtém sucessoapenas parcial (foi possível analisar algumas fases ou algumas estruturas de dados doprograma, mas não todas), então aquelas fases ou estruturas de dados para as quais aanálise obteve sucesso serão beneficiadas com execução otimizada.
A figura 2.1 apresenta o modelo hierárquico de programação. O programade memória compartilhada é submetido a um compilador, que analisa o código fonte daaplicação e insere no código diretivas que serão utili zadas pelo ambiente de execução deDSM.
FIGURA 2.1 – Modelo de programação
2.1.2 Compilador e Ambiente de Execução
O ambiente de programação paralela PARASCOPE [KEN 93] foi estendidopara analisar e transformar programas paralelos. O compilador utili za Análise deSeções Regulares (Regular Section Analysis) [HAV91] para determinar o padrão deacesso aos dados compartilhados entre pontos de sincronização. São criados osDescritores de Seção Regular (RSD – Regular Section Descriptors), usados paraidentificar oportunidades para agregação de comunicação, redução do overhead deconsistência, união das mensagens de sincronização e de dados, e substituição desincronização barreira por sincronização ponto-a-ponto. Também foi estendida ainterface para o sistema TreadMarks para que este possa suportar as primitivas geradaspela análise de compilação [DWA 96] e [LU 97].
TreadMarks é um sistema DSM implementado em nível de softwaredesenvolvido na Rice University [AMZ 96] e [KEL 94]. TreadMarks fornece primitivasde programação distribuída explícita similares as util izadas em máquinas de memóriacompartilhada. O TreadMarks utili za o modelo de Consistência de L iberaçãoPreguiçosa de memória (LRC – Lazy Release Consistency) [KEL 98], exigindo doprogramador a utili zação explícita das primitivas de sincronização do sistema paragarantir que mudanças nos dados compartilhados tornar-se-ão visíveis.
O hardware de memória virtual é utili zado para detectar acessos à memóriacompartilhada. Conseqüentemente, a unidade de coerência [ARA 99] é a página dememória virtual. O protocolo de vários escritores reduz os efeitos de falsocompartilhamento decorrentes do grande tamanho da unidade de coerência. Com esteprotocolo, dois ou mais processadores podem simultaneamente modificar sua própria
Programação no Paradigmade Memória Compartilhada
Compilador
Ambiente de DSM
Arquitetura Distribuída
15
cópia da página compartilhada. As modificações são reunidas na próxima operação desincronização, de acordo com o modelo de consistência de memória. As atualizaçõessão realizadas com a utili zação dos diffs. O diff é uma estrutura de dados criada a partirda comparação realizada entre a página modificada com uma cópia inalterada da página(chamada twin).
O modelo de consistência de liberação preguiçosa permite que a propagaçãodas modificações seja postergada até o momento da próxima operação de obtenção.Neste momento, o processador que está realizando a obtenção recebe os avisos deescrita (write notices) sobre as páginas que foram modificadas. Os avisos de escrita sãoaplicados causando a invalidação das páginas correspondentes. Como resultado, napróxima vez que a página for acessada irá ocorrer uma falha de página, sendo que seránecessário requisitar as modificações realizadas na página para torná-la válida. Osavisos de escrita informam ao processador de onde devem ser requisitados os diffs paraserem aplicados à página.
2.1.3 Análise de Compilação
O intuito da análise de compilação é fornecer informações sobre o padrãodos acessos à memória para o ambiente de execução. Para isso, os comandos do códigofonte da aplicação são analisados para determinar como e quais os dados são acessados.As informações coletadas pelo compilador são colocadas junto das operações desincronização. Isso porque são nesses pontos da execução do programa distribuído quesão determinados quais dados modificados em outros processadores precisam serrefletidos localmente para a memória tornar-se consistente. Portanto, é analisado osegmento de código entre duas operações consecutivas de sincronização e fornecida adescrição para o ambiente de execução na operação de sincronização inicial dosegmento.
A principal ferramenta para realizar a análise do comportamento dosacessos à memória é a análise de seções regulares. A partir dessa análise são criados osdescritores de seções regulares que são utili zados como uma representação concisasobre os acessos a vetores do próximo laço. Os RSDs representam os dados acessadoscomo expressões lineares das extremidades superior e inferior do laço. Quando estãoenvolvidos vetores indiretos, os RSDs podem ser usados recursivamente, representandouma seção regular para o vetor indireto em questão. Contudo, o padrão de acessos quepodem ser analisados são limitados às expressões lineares dos índices dos laços. Alémdas posições de memória acessadas, os RSDs também contém uma tag indicando, entreoutras coisas, se os acessos são de leitura, de escrita, ou de leitura e escrita. Maisdetalhes sobre o algoritmo de análise de compilação podem ser obtidos em [DWA 99].
2.1.4 Ambiente de Execução Incrementado
O sistema TreadMarks foi incrementado para suportar as duas primitivasque são incluídas pelo compilador para auxili ar o ambiente de execução: Validate ePush.
Validate e sua variante Validate_w_sysnc suportam comunicaçãoagregada. Permitem que sejam requisitados múltiplos diffs com uma única troca demensagem. Além disso, Validate_w_sysnc, anexa as requisições por diffs na
16
próxima mensagem de sincronização. A utili zação das primitivas Validate fornecemum conjunto de descritores de acessos correspondendo aos RSDs obtidos na análise(seção 2.1.3). O ambiente de execução usa estes descritores para determinar umconjunto de páginas inválidas que serão acessadas. Sendo assim, dados das páginasinválidas podem ser requisitados em uma única troca de mensagem por processador.
A primitiva Validate possui como argumento vários descritores deacesso. Um descritor de acesso consiste do RSD da seção, do tipo de acesso e doschedule_number. O RSD contém o endereço base, a dimensão ou o tamanho do vetore uma indicação informando se o acesso é direto ou indireto. Se o acesso for direto,são incluídas informações sobre a posição inferior e superior do vetor e o passo. Se forindireto, é armazenado o RSD para o vetor indireto.
O tipo de acesso pode ser read, write ou read& write. Vetorescompartilhados acessados diretamente ao longo de cada dimensão possuem dois tiposadicionais de acessos: write_all e read& write_all , os quais são usados quando aanálise de compilação puder determinar que todos os elementos da seção anterior serãoescritos. O ambiente de execução utili za estas informações para reduzir o overhead demanutenção da consistência eliminando a criação twins e diffs para tais páginas (umavez que todos os dados compartilhados foram modificados, não há benefício nautili zação de diffs). Além disso, já que os acessos marcados como write_all não sãolidos, o ambiente de execução pode evitar a comunicação para tornar estes dadosconsistentes antes da escrita.
O schedule_number é um identificador para o escalonador ou o conjunto depáginas compartilhadas acessadas na seção. Para acesso indiretos, este conjunto érecalculado. O ambiente de execução usa o mecanismo de proteção de memória virtualpara detectar quaisquer modificações nos vetores indiretos. Isso elimina a necessidadede conhecimento em tempo de compilação de quando o vetor indireto será modificado.
A primitiva Validate_w_sync é similar a Validate, exceto que arequisição por dados é anexada na mensagem de sincronização.
A primitiva Push é utili zada para substituir sincronização de barreira e paraenviar dados para um processador antes de serem requisitados. Os argumentos do Pushsão as seções de dados que são escritas por processadores distintos antes da barreira elidas após a barreira. Um Push em um processador P calcula a intersecção das seçõesescritas por P com aquelas que serão lidas por outro processador, e envia os dados daintersecção para o processador correspondente. P então calcula a intersecção das seçõesescritas por outros processadores com as seções que serão lidas por P, e fixa um receivepara estes dados.
Diferente do Validate, que não altera a consistência de memória (amenos que seja especificado um write_all ou um read& write_all ), o Push garanteconsistência somente para as seções de dados recebidas através do Push. O resto doespaço de endereçamento compartilhado pode estar inconsistente até a próxima barreira.Portanto, o Push será utili zado somente quando o compilador tiver determinado comcerteza que as regiões de dados compartilhadas que ficarão inconsistentes não serãolidas. Com unidades de consistência grandes, a diretiva Push poderá ser útil poreliminar comunicação de dados provenientes de falso compartilhamento. Push forneceas facil idades de uma interface de troca de mensagens dentro de um ambiente dememória compartilhada. Contudo, diferente das propostas puramente baseadas emcompilação, Push pode ser utili zado seletivamente por restringir sua utili zação para
17
fases do programa onde é possível uma análise completa. O ambiente de execuçãogarante que todo o espaço de endereçamento estará consistente na barreira que termina afase.
O compilador transforma o código fonte do programa usando essas duasprimitivas. Primeiro, o compilador tenta encontrar oportunidades para utili zar aprimitiva Push, pois esta resulta em maiores ganhos de desempenho. Posteriormente,tenta encontrar oportunidades para usar o Validate.
2.2 Supor te de Compilação para o CVM
O suporte de compilação para o CVM permite que aplicações seqüenciaissejam portadas para arquiteturas distribuídas com o auxílio de um compiladorparalelizador em um ambiente de execução baseado em memória compartilhadadistribuída.
2.2.1 Introdução
A programação para máquinas que utili zam troca de mensagens (arquiteturadistribuída) pode ser realizada a partir de construções explícitas (grande esforço deprogramação) ou por compiladores paralelizadores (aplicabili dade limitada, pois nãoconseguem gerar código otimizado para determinados tipos de aplicações). Uma formade eliminar estas restrições é combinar um compilador paralelizador para memóriacompartilhada com um sistema DSM implementado em nível de software. A propostade Keleher e Tseng [KEL 97] combina o compilador paralelizador SUIF [HAL 95] e osoftware DSM CVM (Coherent Virtual Machine – Máquina Virtual Coerente) [KEL96]. O SUIF paraleliza automaticamente aplicações seqüenciais, além de fornecer umaanálise sofisticada do código. O programa é compilado para executar em CVM, o qualabstrai os detalhes da arquitetura distribuída que requer troca de mensagens (figura 2.2).
FIGURA 2.2 – Modelo de paralelização SUIF/CVM
As inovações do sistema incluem técnicas de compilação que: (i) combinammensagens de dados da aplicação e de sincronização com a invocação de tarefasparalelas; (ii ) emprega rotinas para avaliação de operações reduzidas; (iii ) seleciona um
Programa Seqüencial
Compilador Paralelizador
Ambiente de DSM
Arquitetura Distribuída
18
protocolo de atualização híbrido que envia dados antecipadamente (flushing) realizandoatualizações nas barreiras. Atualizações antecipadas (flushing updates) eliminamvárias falhas de memória não locais, aumentando assim o desempenho.
Para complementar a proposta de Keleher e Tseng, Han et al. [HAN 97] e[HAN 98] propuseram algoritmos para eliminação de sincronização de barreira a partirda análise de compilação. As técnicas de compilação para reduzir o overhead desincronização e desbalanceamento de carga foram implementados com os objetivos de:
� Realizar uma análise de comunicação através de análise de subscriçãolocal (local subscript);
� Explorar consistência de liberação preguiçosa para eliminar barreirasguardando apenas anti-dependência;
� Substituir barreiras (que envolvem todos os processadores) poroperações de sincronização que envolvam apenas os mais próximos.
Esses objetivos são melhor explicados na seção 2.2.4 (subseções A, B e C,respectivamente). Sendo que maiores detalhes podem ser obtidos em [HAN 97] e [HAN98].
2.2.2 Compilador e Ambiente de Execução
O objetivo dos compiladores paralelizadores é identificar laços ou tarefasparalelas em programas seqüenciais. Isso é realizado utili zando análise dasdependências e do fluxo dos dados combinada com transformações no programa. Umavez que porções paralelas do programa são identificados, esta porção é colocada nocorpo de um procedimento, o qual pode ser invocado por todos os processadores emparalelo.
SUIF é um compilador paralelizador e otimizador desenvolvido em Stanford[HAL 95]. O código gerado pelo SUIF assume a semântica de memória compartilhada.Como a maioria dos compiladores paralelizadores de memória compartilhada, o SUIFemprega tipicamente o modelo de programação fork-join, onde uma thread centralexecuta as porções seqüenciais do programa, atribuindo (forking) computações para asthreads trabalhadoras. Após completar sua porção do laço paralelo, a thread centralespera para que todas as threads trabalhadoras completem (join) seu trabalho paracontinuar a execução.
Esse modelo impõe dois eventos de sincronização por laço paralelo.Primeiro, uma barreira é inserida antes do corpo do laço para acordar as threadstrabalhadoras disponíveis e fornecer aos trabalhadores o endereço da computação a serexecutada e os parâmetros se necessário. Uma barreira é inserida após o corpo do laçopara garantir que todas as threads trabalhadoras tenham completado e a thread centralpossa continuar.
O sistema DSM usado neste trabalho é o CVM, um software DSM quesuporta vários protocolos e modelos de consistência de memória [KEL 97]. O sistemafoi escrito em C++ e fornece um conjunto de classes que implementam um protocologenérico, threads e comunicação. A comunicação é baseada em um protocolo ponto-a-ponto construído sobre UDP.
19
O CVM utili za como modelo de consistência de memória o modelo deconsistência de liberação preguiçosa em conjunto com um protocolo de múltiplosescritores. O funcionamento do protocolo de múltiplos escritores em conjunto com omodelo de consistência de liberação preguiçosa foram brevemente descritos na seção2.1.2, sendo que para análises mais detalhadas é possível consultar [ARA 99] e [KEL97].
2.2.3 Interface Compilador / Software DSM
Parece intuitivo que compiladores que geram código para arquiteturas dememória compartilhada e sistemas DSM complementam-se. No entanto, é preciso criaruma interface entre o compilador (SUIF) e o sistema DSM (CVM). A forma encontradapara criar a interface foi modificar o SUIF para gerar código para o CVM fornecendouma interface baseada nas primitivas do CVM para criação de threads e sincronização.
Uma das características dos softwares DSM é utili zar um protocolo deinvalidação para manter a coerência. No entanto, este protocolo é ineficiente parapadrão de comunicação produtor-consumidor, particularmente se houverem váriosconsumidores. Por exemplo, se p produz o dado X consumido pelo processador q. Se Xfor alterado, p invalida a cópia de X mantida por q. Usando LRC, a mensagem deinvalidação é anexada a mensagem de sincronização de barreira, de modo que ooverhead de invalidação é baixo. Entretanto, quando q tentar consumir X, irá ocorreruma falha de página, sendo necessário requisitar a cópia válida de p. Se váriosprocessadores consumirem X, o produtor p irá receber um grande número derequisições.
Para eliminar esses efeitos, considera-se os lugares onde relações produtor-consumidor ocorrem no programa. Uma primeira solução para o problema é anexarjunto com a mensagem de sincronização as atualizações que o compilador podeidentificar que serão necessárias no próximo laço. Um processador central controla oinício da fase paralela, enviando uma mensagem de broadcast para todas as threadstrabalhadoras. Nesta mensagem de sincronização pode ser adicionado aquelas variáveisidentificadas pelo compilador que possuem o comportamento de produtor-consumidor,fazendo com que sejam automaticamente atualizadas com novos valores.
Outra oportunidade de otimização é utili zar um suporte para reduções.Reduções são ações comutativas (p.e., soma, máximo) identificadas pelo compiladorque são executadas em dados locais e acumuladas em posições globais. CVM suportareduções copiando o operador de redução e o dado de redução local em um registro deredução local. Todos os registros são adicionados na próxima mensagem de barreira,atualizando o valor do dado global compartilhado. Como vantagens de centralizar oprocesso de redução, tem-se eliminada a sincronização de exclusão mútua, uma vez quea thread central é que vai realizar todas as reduções. Além disso, já que as reduções sãoexecutadas na memória compartilhada, centralizando o processo na thread central evitaque as páginas tenham que ser requisitadas em todas as memórias locais e que tenhamque ser criados diffs em cada uma dessas máquinas.
CVM controlam cópias das páginas compartilhadas utili zando copysets, queespecificam quais processadores possuem na sua memória local determinada página.Esta informação pode ser utili zada para melhorar o desempenho, aplicandoseletivamente um protocolo híbrido, ora utili zando invalidação ora utili zandoatualização. A coerência das páginas que são normalmente comunicadas entre o mesmo
20
conjunto de processadores, podem ser atualizadas antecipadamente ao invés deatualizadas após escritas, eliminando falhas de acesso. A coerência para as outraspáginas é mantida com o protocolo de invalidação para evitar comunicação excessiva.Na primeira iteração de um laço, os copysets de cada página estão vazios e falhas deacesso ocorrerão. Na segunda iteração, a informação de copyset indica os processadoresque necessitam cada página, refletindo um padrão estável de compartilhamento. Com autili zação do protocolo flush, falhas de acesso podem ser eliminadas atualizando osprocessadores (através do copyset da página) com os dados necessários antes de seremutili zados.
2.2.4 Reduzindo o Overhead de Sincronização
O modelo fork-join impõe dois eventos de sincronização por laço (figura2.3(A)). As operações de sincronização podem degradar significativamente odesempenho. Operações de barreira causam overhead no ambiente de execução eexigem que todos os processadores esperem por um processador mais lento,desperdiçando poder computacional que poderia estar sendo utili zado porprocessamento. O overhead de sincronização de barreira é mais significante quando onúmero de processadores aumenta, já que o intervalo entre barreiras diminui devido àcomputação ter sido particionada entre mais processadores.
A eliminação de barreiras por compilação é possível a partir da observaçãoque sincronização entre um par de processadores é necessária somente se elescomunicam dados compartilhados [HAN 97] e [HAN 98]. Se a análise de dependênciade dados puder mostrar que dois laços adjacentes acessam conjuntos disjuntos de dados,então a barreira sincronizando ambos pode ser eliminada, como na figura 2.3(B).
FIGURA 2.3 – Otimizações identificadas pelo compilador
Se dois laços acessam os mesmos dados, mas a análise da comunicaçãoprova que dados remotos não são acessados, baseado em informações sobre adecomposição dos dados e da computação, a barreira pode ser eliminada, como na
21
figura 2.3(C). Finalmente, se a análise de comunicação identifica um padrão decompartilhamento interprocessador simples, a barreira pode ser substituída por formasmenos caras de sincronização (envolvendo um número menor de processadores). Emparticular, se dados são compartilhados somente com os processadores vizinhos, abarreira pode ser substituída por sincronização somente com os vizinhos, como mostra afigura 2.3(D). Cada uma dessas otimizações será discutida nas próximas três subseções.
A) Análise da Comunicação
Assume-se que a análise de dependência já tenha eliminado todos os paresde referência a vetores entre laços adjacentes, provando acessarem posições disjuntas dememória. Análise de subscrição local baseia-se no compilador selecionar pedaçosconsistentes das iterações do laço paralelo. Iterações consistentes de laços serão sempreatribuídos ao mesmo processador. Se todos os pares subscritos forem idênticos, cadaprocessador acessará somente dados locais. Se a subscrição diferir em um determinadovalor X, então cada processador irá acessar dados remotos de X processadores adiante.Uma vez que a diferença na subscrição normalmente é baixa (valor X baixo),processadores acabarão acessando dados remotos nos processadores vizinhos,permitindo que barreiras sejam substituídas por sincronização entre algunsprocessadores.
B) Explorando a Consistência de Liberação Preguiçosa
Uma segunda melhoria para o algoritmo de eliminação de barreira emtempo de compilação é possível devido a semântica do modelo de liberação preguiçosa.No modelo tradicional de memória compartilhada, sincronização é necessária entre doislaços próximos se dois processadores acessam dados compartilhados, com ao menos umdos processadores executando uma escrita aos dados compartilhados. No entanto, se areferência compartilhada é uma leitura no primeiro laço e uma escrita no segundo, não énecessária sincronização, pois escritas do segundo laço não irão tornar-se visíveis aleitura do primeiro laço. Em outras palavras, anti-dependência (escrita-após-leitura) nãoprecisa de sincronização.
C) Customizando a Sincronização
Em algumas barreiras, o compilador pode detectar que existe comunicaçãosomente entre os processadores vizinhos. Para tirar vantagem dessa informação, foiimplementada uma rotina customizada para sincronização com os processadoresvizinhos (onde cada processador possui nenhum, um ou dois vizinhos) diretamente noCVM. A rotina envia uma mensagem para cada processador vizinho informando achegada a barreira e continua tão logo sejam recebidas as mensagens de todos osprocessadores vizinhos. Em comparação, para barreiras globais todos os processadoresenviam uma mensagem para o mestre de barreira, o qual envia um broadcast deresposta quando todos os processadores tiverem chegado.
22
2.3 Comparação
As propostas apresentadas nesse capítulo são baseadas em um suporte decompilação para identificar possíveis otimizações no código fonte da aplicação. Oscompiladores procuram por pontos onde é possível determinar estaticamente ocomportamento que a aplicação irá apresentar durante a execução e transformar ocódigo para obter melhor desempenho.
O suporte de compilação para o TreadMarks analisa o código desenvolvidono paradigma de memória compartilhada e acrescenta primitivas (chamadas) paraauxili ar o ambiente de execução. Essas primitivas informam sobre o comportamentodos acessos à memória compartilhada no próximo laço. As informações são inseridas naoperação de sincronização (obrigatoriamente as primitivas de sincronização da API doTreadMarks) que precede o laço. O TreadMarks precisou ser modificado para suportaras primitivas.
Por outro lado, o suporte de compilação para o CVM permite que aplicaçõesseqüenciais sejam portadas para arquiteturas distribuídas com o auxílio de umcompilador paralelizador e de um ambiente de execução baseado em memóriacompartilhada distribuída (DSM). A proposta de suporte de compilação para o CVMaltera o código fonte nos pontos onde a análise estática detectou que otimizações sãopossíveis. O ambiente de execução não precisou ser alterado, já que não há a inclusãode novas primitivas.
No suporte de compilação para o TreadMarks essas informações sãorepassadas para o ambiente de execução através da utili zação das primitivas Push(substitui sincronização de barreira por sincronização ponto-a-ponto e envia dados antesde serem requisitados) e Validate (agrega comunicação). As informações sobre ocomportamento futuro dos acessos à memória evitam a necessidade do ambiente deexecução detectar os acessos à memória e buscá-los sob-demanda. Além disso,permitem a agregação e várias requisições de dados em uma única troca de mensagempor processador.
No suporte de compilação para o CVM o processo é diferente. Ocomportamento dos acessos à memória é analisado e o código da aplicação émodificado sem a inclusão de novas primitivas. O protocolo que é responsável porenviar dados na operação de sincronização anterior a sua real utili zação é flushingprotocol. A eliminação de barreira é realizada diretamente no código fonte, de formatransparente para o ambiente de execução.
No trabalho de Ioannidis [IOA 98] as informações coletadas pelocompilador são utili zadas para auxili ar o algoritmo de balanceamento de carga. Ocompilador fornece as informações sobre o padrão de acessos nos pontos do código quesão executados em paralelo. O ambiente de execução usa esses pontos para coletarestatísticas dos recursos computacionais e de comunicação disponíveis. Baseado nopadrão de acessos entre as fases, bem como no poder computacional disponível, oambiente de execução pode tomar decisões sobre a distribuição da carga. Além disso,pode maximizar a localidade dos dados e minimizar o overhead de comunicação nofuturo.
23
3 Técnicas para Evitar Falso Compar tilhamento
Este capítulo trata de técnicas aplicadas para o evitar os efeitos de falsocompartilhamento. A seção 3.1 apresenta o problema no contexto de sistemas DSMcom modelo de consistência de liberação preguiçosa e protocolo de vários escritores. Aseção 3.2 trata de uma proposta que agrega dinamicamente as páginas aumentando aunidade de coerência. Ao contrário, a proposta da seção 3.3 divide a página em visões,diminuindo a unidade de coerência. Finalmente, a seção 3.4 realiza uma brevecomparação do que foi abordado no capítulo.
3.1 Efeitos do Falso Compar tilhamento
A descrição sobre falso compartilhamento realizada neste capítulo aplica-sea um sistema DSM implementado em software baseado em página que utili zaconsistência de liberação preguiçosa e protocolo de vários escritores. LRC e protocolode vários escritores aliviam os piores efeitos do falso compartilhamento. Em particular,leituras e escritas concorrentes a mesma página não causam comunicação no momentodo acesso. No entanto, causam comunicação extra na forma de mensagensdesnecessár ias ou mensagens com dados desnecessár ios [AMZ 97].
Mensagens desnecessárias são produzidas por falso compartilhamento deescrita-escr ita. Por exemplo, se P1 e P2 escrevem na mesma página, P1 na metadesuperior e P2 na inferior. Após todos os processadores alcançarem a barreira, P3 lê ametade superior da página. Intuitivamente, o processador P3 precisaria somente dosdados produzidos por P1, e portanto, uma única troca de mensagens com P1 seriasuficiente. Na barreira, entretanto, a cópia da página em P3 é invalidada pelos avisos deescrita de P1 e P2. Quando P3 realizar um acesso de leitura na página, serão requisitadosos diffs de P1 e P2. As mensagens trocadas com P2 são mensagens desnecessáriascausadas por falso compartilhamento de escrita-escrita.
Mensagens com dados desnecessários ocorrem em conjunto comcompartilhamento real (true sharing). Entretanto, esse efeito é classificado como falsocompartilhamento devido a implicar comunicação não estritamente exigida pelocompartilhamento real. Por exemplo, se o processador P1 modifica a página inteira, edepois sincroniza-se com o processador P2. Mesmo que P2 acesse somente a metadesuperior da página, receberá página inteira. A metade inferior enviada no diff são dadosdesnecessários.
Nas redes de estações de trabalho (NOWs) atuais, o custo de enviarmensagens extras é normalmente bem mais alto do que o custo de enviar dadosadicionais em mensagens. O efeito de falso compartilhamento é primeiramentedeterminado pelo número de mensagens desnecessárias e somente em segunda ordempela quantidade de dados desnecessários presentes nas mensagens [AMZ 97]. Estecapítulo descreve técnicas que tentam reduzir esses efeitos.
24
3.2 Agregação de Páginas
Este seção apresenta a proposta desenvolvida por Amza et al. [AMZ 97] quebaseia-se na utili zação de grandes unidades de coerência, formada por grupos depáginas.
3.2.1 Introdução
Sistemas DSM baseados nas técnicas de memória virtual utili zam a páginado hardware como unidade de coerência O tamanho da página do hardware éconsiderado grande, sendo muitas vezes considerado o responsável pelo overhead defalso compartilhamento. Amza et al. tentam provar o contrário, que na presença de ummodelo de consistência relaxado de memória e um protocolo de vários escritores, umaunidade de coerência grande não é um fator que degrada o desempenho. Sãoconsiderados os efeitos de falso compartilhamento e agregação quando usadas grandesunidades de coerência.
É apresentado um algoritmo que agrega dinamicamente páginas em gruposde páginas. Em uma falha de página, todas as páginas do grupo são validadas ao mesmotempo. As páginas pertencentes ao grupo não precisam ser contínuas. O algoritmomonitora o comportamento das falhas de página das páginas individuais para estardevidamente informado e poder decidir por agrupar páginas em grupos ou por dividirdeterminado grupo. Contudo, há o custo para monitorar o comportamento das falhas depágina.
3.2.2 Agregação Dinâmica
A escolha por grandes unidades de coerência apresenta como vantagens aredução do número de falhas de acesso e do número de operações de consistência,incluindo operações de proteção a memória, criação de twins e de diffs. Em termos decomunicação, a aplicação de grandes unidades de coerência aumenta potencialmente ofalso compartilhamento.
Algumas aplicações podem beneficiar-se de unidades de coerência grandes,enquanto para outras o desempenho pode ser deteriorado. Como solução, pode serempregado um algoritmo de agregação dinâmica que junta páginas em grupos depáginas, baseado nos seus padrões de acesso. O algoritmo monitora o padrão de acessosem cada processador e tenta construir grupos de páginas, tal que aumente a agregaçãosem incorrer nos efeitos de falso compartilhamento.
Os diffs para todas as páginas do grupo são requisitados na primeira falha dequalquer uma das páginas que é membro do grupo. Várias requisições endereçadas parao mesmo processador são combinadas, resultando em poucas mensagens paratransferências de dados para o grupo como um todo. Até mesmo se os diffs foremrequisitados de processadores distintos, ainda existe a vantagem de requisitar os diffspara todas as páginas do grupo de uma vez, permitindo que os processadores retornemos diffs em paralelo e não seqüencialmente.
Os grupos de páginas são calculados a cada operação de sincronização.Essencialmente, o algoritmo agrupa páginas que foram acessadas antes da sincronização
25
(até um número máximo de páginas por grupo) de forma que possam ser requisitadascomo um grupo se forem acessadas novamente após a sincronização.
Com o objetivo de traçar o padrão (comportamento) de acessos para umapágina, o algoritmo mantém cada página inválida até o primeiro acesso à página. Aocorrência de uma falha de página significa um acesso à página. Uma página pode sermantida inválida, embora já tenha sido atualizada no primeiro acesso a outra página dogrupo. Se ocorrer uma falha para tal página no grupo, não haverá a necessidade derequisitar dados, pois todas as atualizações já foram recebidas. Esta estratégia permiteao algoritmo detectar qualquer mudança no padrão dos acessos do programa durante aexecução.
Comparado com a utili zação estática de uma grande unidade de coerência,esse simples algoritmo de agregação dinâmica captura os “bons” casos de agregação eevita os “maus” casos de falso compartilhamento. Quando várias páginas são acessadaspor um processador, o algoritmo registra este fato, e as busca em conjunto após apróxima sincronização, independente do número de escritas concorrentes. Este éexatamente o comportamento dos algoritmos de agregação estática, quando elesalcançam sucesso. Reciprocamente, quando o processador não acessar várias páginasjuntas, o algoritmo observa este comportamento, e volta a utili zar páginas, evitandoassim os cenários onde falso compartilhamento tem um efeito negativo no desempenhocom agregação estática. Além disso, o algoritmo de agregação dinâmica beneficia-sepor não restringir que sejam agrupadas somente páginas contínuas.
As desvantagens da agregação dinâmica comparada com a utili zaçãoestática de grandes páginas são as falhas de página extras e as operações de proteção dememória necessárias para identificar o padrão de acessos. Além disso, existe um efeitode histerese na detecção de mudanças no padrão de acessos, o que pode causar algumasmensagens desnecessárias, enquanto o esquema reconstitui o grupo de páginas.Entretanto, estas mensagens desnecessárias podem ser compensadas com a requisiçãode diffs para a página faltando. Estas desvantagens são pequenas comparadas com osganhos obtidos por evitar o falso compartilhamento [AMZ 97].
Os testes realizados por [AMZ 97] mostram que a técnica reduz o númerode mensagens desnecessárias, mas aumenta o número de mensagens com dadosdesnecessários.
3.3 Adaptable View
A técnica Adaptable View [ITZ 99a] implementa várias granularidades decompartilhamento em sistemas DSM baseados em páginas.
3.3.1 Introdução
Se, por um lado, granularidades finas podem eliminar falsocompartilhamento e fragmentação e reduzir o tráfego desnecessário na rede, por outrolado, granularidades grossas reduzem o número de falhas de páginas e de outrasoperações do protocolo de consistência. Portanto, o desempenho pode ser melhoradofixando diferentes níveis de granularidade nos diferentes estágios da execução.
26
O objetivo da técnica Adaptable View é implementar várias granularidadesde compartilhamento em sistemas DSM baseados em páginas. São utili zados protocolosque alteram durante a execução entre unidades de compartilhamento grandes epequenas. Itzkovitz et al. [ITZ 99a] defendem que as aplicações podem ser beneficiadaspela adaptação do tamanho da unidade de compartilhamento da memória ao padrão deacessos à memória, usando tanto compartilhamento de grão grosso quanto de grão finointercaladamente nos diferentes estágios da computação.
3.3.2 MultiView
A granularidade de compartilhamento de dados de sistemas DSM baseadoem páginas é o tamanho da página de memória, que é normalmente poucos Kb. Estaunidade de compartilhamento é considerada bem maior do que o efetivocompartilhamento das aplicações. No sistema MultiView [ITZ 99], o espaço deendereçamento compartilhado é mapeado em várias regiões de endereços virtuais,chamadas visões (views).
Um elemento de memória do espaço de endereçamento compartilhado podeser acessado através das visões utili zando os mecanismos de mapeamento de memóriavirtual. MultiView permite ao sistema DSM manipular cada elemento de memória(minipage) através de uma página dedicada da memória virtual que pertence a uma dasvisões. A proteção para a minipage é controlada manipulando a proteção da página dememória virtual associada.
A figura 3.1 demonstra um layout simples da memória de um sistema DSMque utili za o MultiView. As variáveis compartilhadas x, y e z são alocadas na mesmapágina, mas o falso compartilhamento é evitado associando cada variável com umavisão separada, portanto, cada variável reside na sua própria minipage.
FIGURA 3.1 – Várias visões
Adaptable View estende o MultiView fornecendo várias granularidadescontroladas pela aplicação durante uma única execução. Isto é, o tamanho da unidade decompartilhamento é adaptado ao padrão de acessos à memória da aplicação. OAdaptable View foi implementado no sistema Milli page [ITZ 99].
27
3.3.3 Vár ias Granular idades de Compar tilhamento
Considera-se um programa composto de fases. Em certas fases,processadores lêem relativamente largas seções da memória, ou escrevem para regiõesde memória que não são acessadas por outros processadores. Em outras fases, cadaprocessador atualiza uma porção de variáveis cuja localização na memória é intercaladacom variáveis acessadas por outros processadores. A primeira fase será referenciada porfase grossa (coarse phase) e a segunda por fase fina (fine phase).
Um programador que util ize o MultiView pode alocar cada elemento damemória em uma minipage separada para evitar falso compartilhamento. Claramente,essa é a melhor escolha para o padrão de acessos à memória da fase fina. Entretanto,acessando uma larga região de memória em uma fase grossa subseqüente causará váriasfalhas que serão manipuladas pelo sistema DSM. O desempenho pode ser melhoradopara fase grossa se o tamanho do grão de compartilhamento for aumentado. Sendoassim, vários elementos de dados serão alocados na mesma minipage.
Com o MultiView, uma página contendo k elementos de dados pode sermapeada em k visões. Tal esquema de alocação de memória é dito comocompartilhamento de nível k. A memória usada por cada variável pode ser sobreposta(distribuída) em l visões, isto é, cada variável pode ser associada com l minipagesdistintas, de tamanhos diferentes, cada uma fornecendo um nível diferente decompartilhamento. Todas as minipages associadas com as mesmas variáveis são apenasformas diferentes de acessar os dados, os quais estão contidos no espaço deendereçamento compartilhado. Acessando variáveis através de minipages com agranularidade mais fina, tem-se compartilhamento de grão fino. Enquanto que,acessando variáveis através de visões largas, tem-se compartilhamento de grão grosso.
A figura 3.2 mostra o mapeamento de memória envolvido para suportar osníveis 4, 2, e 1 de compartilhamento, utili zando o Adaptable View. Quando for umafase fina, o sistema acessa todas as variáveis usando o conjunto de visões do nível decompartilhamento 4 (visões 1-4). Na fase grossa, todos os acessos irão utili zar umaúnica visão, a qual é dada pelo nível de compartilhamento 1 (visão 7).
Em geral, uma certa fase pode ser grossa para um conjunto de variáveis,enquanto pode ser fina para outro conjunto de variáveis. O Adaptable View muda agranularidade de cada conjunto de variáveis independentemente, simplesmenteassociando-as a minipages de diferentes tamanhos.
O Milli page utili za gerentes para armazenar o estado global das minipages,tal como localização e proteção. Os gerentes mantêm informações para as minipages degranularidade mais finas. A disponibili dade de minipages grossas é inferida a partir dadisponibili dade das minipages finas que a compõe. As próximas subseções tratam sobrequestões relativas as trocas de fases.
28
FIGURA 3.2 – Vários níveis de compartilhamento
A) Alterando de uma fase fina para uma fase grossa
Quando altera-se de uma fase fina para uma grossa, uma minipage grossapode estar fragmentada (diferentes partes podem residir em nodos diferentes). Portanto,antes que uma página grossa possa ser utili zada, os dados que compõem as minipagesfinas precisam ser coletados nos nodos que residem, e posteriormente agrupadas.
O gerente inicia o processo de coleta e agrupa as minipages de acordo como estado global (disponibili dade dos dados) da minipage. O gerente pode descobrir queo nodo requisitante já possui todos os dados, então é desnecessário coletá-los, e somentea proteção deve ser trocada. Neste caso, o requisitante é informado que pode trocar aproteção e continua a execução. O gerente pode descobrir que todos os dados daminipage residem em um único nodo remoto. Neste caso, o gerente encaminha arequisição para este nodo remoto. O nodo remoto processa a requisição como se aminipage já estivesse agrupada (resultando em uma única transferência de dados e umaúnica troca de proteção).
No caso mais geral, nenhum nodo possui todas as minipages finas. Então, osfragmentos que não estão disponíveis no requisitante devem ser buscados nas suaslocalizações remotas. O gerente encaminha as requisições para todos os nodos quecontém estes fragmentos, e os nodos enviam os dados diretamente para o requisitante. Ooverhead de comunicação é reduzido agrupando requisições e respostas, tal que somente
29
uma mensagem é enviada para cada nodo. Uma vez que todos os dados chegaram norequisitante, a minipage grossa é agrupada e sua proteção é fixada de acordo com o tipode requisição.
B) Alternando de uma fase grossa para uma fase fina
Durante o serviço de cada requisição para uma minipage grossa, o gerenteatualiza a informação de disponibili dade para as minipages finas que ele contém. Poroutro lado, mudanças locais de proteção não são executadas durante a fase grossa.Quando uma minipage fina é acessada pela primeira vez após ter trocado para umagranularidade mais fina, uma requisição de página é enviada para o gerente. O gerenterepassa a requisição para o nodo que possui o dado requisitado, e o requisitante altera aproteção quando receber os dados.
C) Operação durante uma fase de granularidade fixa
Após a montagem inicial da minipage na granularidade determinada, oprotocolo para processar requisições de minipages é similar a um protocolo utili zadocom granularidades fixas. A aplicação acessa à memória compartilhada usando umponteiro que referencia a minipage apropriada que contém a variável. O endereço iniciale o tamanho da minipage determinam a variação de endereço (extensão) que sãotransferidas e para qual mudança de proteção podem aplicar, de acordo com o modelode consistência. Quando o gerente recebe uma requisição para uma minipage grossa, eleatualiza o copyset para cada uma das minipages mais finas que a compõe.
D) Otimizando a troca de granularidade
Durante a fase de transição, dados são coletados e a proteção das minipagessão fixadas nas visões de acordo com seu estado global. Executar estas tarefas paratodas as minipages exige muita comunicação e é desnecessária para minipages que nãoserão acessadas na próxima fase.
Essa penalidade pode ser evitada adotando uma proposta preguiçosa.Durante a troca de granularidade, a proteção de todas as visões é setada para noaccess, eos dados não são coletados. Isto torna a troca de granularidade muito eficiente. Se equando uma minipage é acessada uma falha ocorre e o controlador de falhas coleta asminipages de forma consistente.
Na há a necessidade de setar a proteção das minipages de granularidadeantiga, já que a aplicação não as acessa na nova fase. A consistência das minipages épreservada na nova granularidade, já que sua proteção é primeiro setada para noaccess eentão modificada por cada nodo de acordo com seu novo estado, mas somente quandotodos os dados estiverem disponíveis.
30
3.4 Comparação
Sistemas DSM baseados nas técnicas de memória virtual utili zam a páginado hardware como unidade de coerência. A proposta de agregação dinâmica reúnepáginas que possuem os padrões de acesso semelhantes em grupos, aumentando assim otamanho da unidade de coerência múltiplas vezes o tamanho da página da memóriavirtual. Quando o algoritmo detecta que a agregação não é mais vantajosa, o grupo édesfeito e a unidade de coerência volta a ser a página. Em uma falha de página, todas aspáginas do grupo são validadas ao mesmo tempo. Contudo, há o custo para monitorar ocomportamento das falhas de página.
A escolha por grandes unidades de coerência apresenta como vantagens aredução do número de falhas de acesso e do número de operações de consistência,incluindo operações de proteção a memória, criação de twins e de diffs. Em termos decomunicação, a aplicação de grandes unidades de coerência aumenta potencialmente ofalso compartilhamento. Essa técnica reduz o número de mensagens desnecessárias, masaumenta o número de mensagens com dados desnecessários.
Por outro lado, a técnica Adaptable View trata de granularidades finas egranularidades grossas. O tamanho do grão de compartilhamento varia desdecompartimento a nível de variável (grão fino) até compartilhamento a nível da página damemória virtual (grão grosso). É possível utili zar unidades de coerência de tamanhointermediário. Granularidades finas podem eliminar falso compartilhamento efragmentação e reduzir o tráfego desnecessário na rede. Ao contrário, granularidadesgrossas reduzem o número de falhas de páginas e de outras operações do protocolo deconsistência. Portanto, o desempenho pode ser melhorado fixando diferentes níveis degranularidade nos diferentes estágios da execução. São utili zados protocolos quealteram durante a execução entre unidades de compartilhamento finas e grossas.
Indicar uma das técnicas como sendo a melhor é uma tarefa árdua,principalmente porque depende muito da aplicação e do compartilhamento da memória.No entanto, a técnica Adaptable View parece comportar-se melhor, pois permitecompartilhamento de grão fino a grão grosso, sendo que a outra proposta só funcionacom grão grosso. No entanto, o overhead de gerenciamento do Adapatble View é maior.
31
4 Escalonamento de Threads
Os algoritmos de escalonamento de threads no contexto de sistemas DSM,além de preocuparem-se com a distribuição das threads entre os processadoresenvolvidos na computação devem preocuparem-se também em manter a localidade dosdados, evitando assim acessos remotos. A seção 4.1 realiza uma introdução sobre oassunto. A seção 4.2 apresenta o mecanismo RAHM, que baseia-se no histórico dosacessos remotos. A proposta descrita na seção 4.3 também leva em consideração osacessos remotos no momento de escalonar as threads. Para concluir o capítulo, a seção4.4 compara as propostas.
4.1 Introdução
Aumentar a eficiência de um sistema de computação uniprocessadordepende principalmente do princípio de localidade, o que leva muitas vezes aodesenvolvimento de hierarquias de memória. Muitos sistemas DSM tentam aplicar oprincípio de localidade, buscando para a memória local da máquina as páginasacessadas pelas threads alocadas na máquina. Entretanto, se existirem threads alocadasem outros processadores que acessem as mesmas páginas, irá ocorrer umamovimentação de páginas entre os processadores, que pode tornar a proposta proibitiva[ITZ 98].
Existem propostas que permitem que isso seja controlado pelo programadorde forma explícita, o que causa um grande envolvimento do programador. Existemtambém sistemas que fazem isso de forma estática, através de compilação, no entanto,não conseguem tratar com sucesso aplicações irregulares. Além disso, ambas aspropostas não tratam de ambientes distribuídos não dedicados.
O objetivo das técnicas apresentadas neste capítulo é reduzirsignificativamente o número de acesso a dados remotos em sistemas DSM. Estamelhoria é obtida automaticamente pelo ambiente de execução que redistribui asthreads de acordo com o modelo de acesso à memória da aplicação. Esses mecanismostêm por objetivo evitar o falso compartilhamento e o efeito ping-pong. Considera-se umsistema DSM implementado em software que utili za a página como unidade decoerência. Se threads alocadas em nodos distintos do sistema compartilharem dados deuma determinada página, o tráfego de compartilhamento somente será eliminado seambas as threads forem alocadas para o mesmo nodo.
Um bom mapeamento de threads para nodos exige vários passos. Primeiro,deve ser possível avaliar a distribuição da carga de um determinado mapeamento.Geralmente, isso pressupõe uma forma de estimar as necessidades computacionais dasthreads e a capacidade computacional dos nodos. A distribuição deve considerar oparalelismo (a quantidade de nodos a serem explorados) e o balanceamento (o quantouniforme a carga está distribuída entre os nodos). Segundo, deve ser possível avaliar ocusto de comunicação de um mapeamento. Isso é determinado identificando ocompartilhamento entre threads alocadas em diferentes nodos. Finalmente, deve serencontrada uma forma de combinar estas métricas em um único algoritmo [THI 99].
Em geral, nem maximização do paralelismo nem minimização dacomunicação pode proceder de forma isolada. Assumindo que o trabalho é distribuído
32
igualmente entre quatro threads: T1 e T3 em um nodo e T2 e T4 em outro. Essadistribuição está balanceada já que cada nodo tem a mesma quantidade de trabalho.Entretanto, em relação à comunicação o sistema não está distribuído da melhor formano caso de cada thread comunicar-se com seus vizinhos (i.e., T2 comunica-se com T1 eT3). Um melhor mapeamento de threads para nodos poderia ser T1 e T2 no primeironodo e T3 e T4 no segundo. Redistribuindo threads para nodos dessa forma, acomunicação é reduzida em um terço sem afetar o balanceamento de carga.
4.2 RAHM
O RAHM (Remote Access History Mechanism – Mecanismo de História deAcessos Remotos) [ITZ 98] e [SCH 98] é um mecanismo que registra o comportamentodos acessos à memória remota, sendo que estas informações são úteis para manter alocalidade dos dados quando realizar o escalonamento de threads.
4.2.1 O Mecanismo
O RAHM é uma técnica que pode ser utili zada para melhorar a localidadedas referências de memória em sistemas de memória compartilhada distribuída (DSM).Isto é realizado dinamicamente e de forma transparente. O RAHM auxili a o ambiente deexecução a tomar decisões corretas no que diz respeito à redistribuição de threads paranodos (operação que tipicamente envolve alto overhead). O RAHM utili za-se dacomunicação existente e adiciona um overhead desprezível.
O RAHM é implementado totalmente em nível de usuário como parte dosistema MILLIPEDE [FRI 97] e [ITZ 97], uma máquina virtual paralela (VPM –Virtual Parallel Machine) projetada para clusters de PC’s não dedicados. Avaliações dedesempenho mostram potenciais melhoras na eficiência de computações paralelas commemória compartilhada em ambientes de memória distribuída, quando aumenta a taxade referências locais à memória.
O método apresentado util iza informações parciais sobre os acesso aosdados (coletados em tempo de execução) para aproximar-se ao comportamento dosacesso à memória da aplicação. O RAHM é uma heurística adaptativa distribuída queesforça-se em melhorar a distribuição das threads de acordo com o comportamento deacesso à memória “observado”, com o objetivo de alcançar a localidade dos acessos adados de DSM.
RAHM coleta informações sobre o padrão de acesso à memória em umaestrutura de dados compacta, chamada de histór ico de acessos da página (page accesshistory). A qualquer momento, esta estrutura de dados pode ser vista como umaaproximação da representação completa do comportamento de acesso à memória daaplicação, contendo parte da informação que pode ser inferida observando as referênciasremotas à memória da aplicação até este ponto. Decisões sobre a redistribuição dacomputação são tomadas consultando estas informações acumuladas.
A aplicação do RAHM é independente da rigidez do modelo de consistênciade memória. Quando as referências à memória são locais devido a uma cópia local doitem, o RAHM está inativo e não apresenta overhead. Esse também é o caso quando,devido a relaxamento do modelo de consistência de memória, existe um único acesso
33
remoto ao item o qual é buscado como uma cópia, e portanto todos os acessossubsequentes também serão locais.
O RAHM só registra eventos que exigem comunicação e não necessita nadasobre a consistência de memória. Porém, seu mecanismo garante que só “acordará”quando o modelo de memória falha, de forma que as referências remotas à memória sãofreqüentes o suficiente para exigir a intervenção. Esta freqüência pode, de fato, ser vistacomo a interpolação de todos os parâmetros importantes: a rigidez do modelo dememória, a taxa de acessos ao item e a taxa de operações de sincronização. Portanto, ocaso de um item que é freqüentemente acessado por uma thread e o modelo de memóriaé fraco, é equivalente, do ponto de vista do mecanismo de RAHM, ao caso de ummodelo rígido de consistência de memória com infreqüentes acessos ao item pelathread.
O RAHM exige somente uma quantidade limitada de recursos e apresentaum pequeno overhead, pois anexa suas mensagens nos eventos de rede já existentes, deforma que a coleta e o armazenamento das informações de acesso são realizadassomente quando ocorrem acessos remotos de memória. O processamento destasinformações e sua utili zação para redistribuição das threads é realizada somente quandofor necessário migrar threads, o que é exigido de alguma forma pelo algoritmo debalanceamento de carga ou quando uma situação de ping-pong é detectada.
4.2.2 Escalonamento de Threads
Uma característica essencial de um sistema DSM é adaptar-se às mudançasque acontecem dinamicamente no ambiente e às necessidades variáveis das aplicações.Uma possibili dade é usar migração de threads para realizar o compartilhamento dacarga entre os nodos do sistema. Entretanto, uma distribuição imprópria de threads podedegradar o desempenho devido ao alto overhead de comunicação. Portanto, as threadsque são escolhidas para migrar quando a política de balanceamento de carga determinar,devem ser selecionadas com cuidado, de forma a minimizar o número de acessosremotos à memória.
Assume-se que algum módulo extra decida que a migração de n threads deum nodo para outro deva ser realizada. A estratégia de seleção de threads éindependente da política de balanceamento de carga, sendo que qualquer algoritmo debalanceamento/compartilhamento de carga pode ser utili zado. O módulo de seleção dethreads concentra-se somente com o problema de otimização para alcançar o máximode localidade. Para isso, são coletadas informações sobre os acessos às páginas remotas,para desta forma “aprender” sobre o comportamento dos acessos à memória.
O mais interessante é que, por razões de desempenho, as informações sobreos acessos locais não são armazenadas. Portanto, o conhecimento sobre o padrão deacessos à memória é incompleto, e por isso, decisões incorretas podem ser tomadas. Porexemplo, quando todas as threads que acessam freqüentemente a mesma página ocupamo mesmo nodo, nenhuma informação (inicialmente) é gravada. Como resultado,algumas destas threads podem ser selecionadas para migrar para outro nodo. Estadecisão será ruim, degradando temporariamente o desempenho. Ao mesmo tempo,informações sobre as páginas tornar-se-ão disponíveis, possibilit ando corrigir a decisão,bem como manter estas informações para melhorar decisões futuras. As próximasseções tratam dessas questões.
34
A) Escolhendo threads para migração
O módulo de seleção de threads preocupa-se somente com o problema deotimização para maximizar a localidade. O módulo recebe como entrada o nodo destinopara a migração e o número de threads para migrar. Começa determinando o conjuntode threads que tem permissão para migrar. Uma thread pode não ter permissão paramigrar por vários motivos. Ela pode ter começado a executar alguma atividadedependente de localização ou pode estar esperando por um evento de sincronização.Além disso, se ela migrou recentemente em uma tentativa de resolver o ping-pong deuma página, uma nova migração pode causar um ping-pong de thread. Considerando Lpara denotar o nodo local e R para denotar o nodo destino da migração, o conjuntoselecionado de threads deve possuir as seguintes características:
� Maior freqüência de acesso remotos a páginas em R – esta condiçãotorna possível diminuir o número existente de transferências de páginasentre L e R;
� Maior freqüência de quaisquer referências remotas – já que aintenção é migrar para um nodo menos carregado, faz sentido moveraquelas com maior demanda de comunicação. Entretanto, esta condiçãoterá menor peso do que a anterior, pois ela não reduz a quantidade totalde comunicação;
� Menor freqüência de acesso das threads que permanecem em L àspáginas utili zadas pela threads selecionada – esta condição tentaminimizar o número de acessos das threads que permanecem em L aestas páginas. Se as threads que permanecem em L não usam estaspáginas, elas podem tornarem-se locais em R;
� Menor freqüência de acesso a páginas locais – uma vez que acessoslocais não são registrados, não há informações que indiquem sobre quaisas threads locais que utili zaram as páginas locais recentemente.Algumas vezes, entretanto, é possível saber que uma thread já usoudeterminada página e que a página é local. Portanto, a condição éaplicada somente quando a freqüência correspondente puder ser inferidaa partir do histórico de execução em outro nodo. Uma determinadathread que já usou uma página (de acordo com o histórico) é assumidacomo ainda utili zando-a.
Estas exigências estão claramente em conflito, sendo necessário uma troca.A solução é deixar que o algoritmo de seleção de threads realize uma estimativa doganho que pode ser obtido migrando cada thread individualmente para o nodo destino.Com essa finalidade, o algoritmo de seleção de threads usa uma função heurística queleva em consideração as informações que estão disponíveis sobre o comportamento doacesso à memória das threads candidatas e o impacto da migração nas outras threads.
Se não existir informações sobre os acessos remotos (i.e., no começo daexecução) ou se existir mais do que uma única escolha, então uma heurística adicional éaplicada: duas threads que foram criadas consecutivamente têm grande chance decompartilharem dados [DUB 98].
35
B) Históricos
Em cada nodo a história local das referências remotas é coletada utili zandodados provenientes do mecanismo de DSM. Para cada acesso remoto, são armazenadasas seguintes informações: id da página, id do host, tipo de acesso, id do host que estáacessando. Estas informações são coletadas em três estruturas de dados diferentes,chamadas de históricos.
A divisão é realizada com o objetivo de simpli ficar a recuperação dasinformações necessárias no momento da decisão. Deve ser tomado cuidado de limitar aquantidade de memória utili zada para armazenar os históricos, enquanto mantéminformações suficientes mesmo quando restrições de memória não permitem armazenaro histórico completo. Além disso, informações desatualizadas devem ser descartadaspara evitar que decisões erradas sejam tomadas devido a eventos passados que nãocaracterizam mais o comportamento corrente. Finalmente, manter os históricosduplicados em diferentes armazenamento também auxili a as cópias com o modelo deconsistência de memória relaxado.
O histór ico da página é mantido em um determinado nodo para cadapágina P que visita o nodo, ao menos que P deixe o nodo e não retorne por “um longoperíodo” , o qual é um parâmetro configurável, denotado por Tepoch. São incluídas asseguintes informações sobre um número limitado dos mais recentes eventos em páginas:
� Tipo do evento – a tentativa de acessar uma página remota, recebimentode uma página remota, enviar a página para outro nodo;
� Id do nodo remoto;� Timestamp (relógio lógico) do evento – é utili zado para descartar
informações para esta página. É importante notar que o timestamp éestritamente local, não existe relógio global no sistema, portanto nãoassume-se nenhum mecanismo de coerência para realizar umordenamento global dos timestamps.
O tamanho do histórico é limitado por cada página. Informaçõesdesatualizadas são removidas do histórico mesmo quando há espaço suficiente paraarmazená-lo.
O histór ico de acessos da thread é mantido para cada thread que estáexecutando localmente. Quando uma thread deixa o nodo seu histórico de acesso vaijunto. O histórico de acesso inclui as seguintes informações sobre um número limitadodos mais recentes acessos remotos:
� Id da página;� Timestamp do acesso.
Os acessos que ocorreram mais do que Tepoch unidades de tempo atrás sãodescartados. Se a página reside localmente, é assumido que a thread continua usando apágina (embora nenhum acesso remoto possa ser armazenado), e a informaçãocorrespondente é armazenada no histór ico reduzido de acessos da thread. Seinformações de acesso forem descartadas devido a limitação de espaço, então o seusumário é armazenado no histórico de acesso reduzido da thread.
36
O histór ico de acessos reduzido da thread contém dados antigos sobreacessos remotos que ocorreram a muito tempo atrás, mas que continuam relevantesdevido a página correspondente tornar-se local e dados de tamanho reduzido sobreacessos que ocorreram recentemente, mas que não podem ser armazenados no históricocompleto devido a limitações de espaço. O histórico reduzido inclui uma entrada paracada página que é referenciada pela thread. A entrada descrevendo a página inclui:
� A freqüência de acessos remotos da thread para página, calculada apartir de toda a história de acessos (antes de serem descartados), e
� O timestamp do acesso mais recente a página (se ele já estiver sidoexcluído da história completa).
Informações sobre as páginas que tornam-se locais mantém-se na históriareduzida para sempre, ou, no caso em que a página deixa de ser local, pela unidade detempo Tepoch.
O histórico de cada página é mantido localmente em cada nodo visitado pelapágina. O histórico da página não migra com a página. Os históricos de acesso dasthreads (completo e reduzido) são mantidos localmente no nodo que está executando athread. Quando uma thread migra para outro nodo, seu histórico completo de acesso éconvertido para o formato reduzido, isto é, são extraídas informações reduzidas sobrecada página do histórico completo e adicionado para o histórico reduzido. O histórico deacessos reduzidos resultante migra junto com a thread e é usado pelo nodo destino paramelhorar futuras decisões.
O RAHM é independente do modelo de memória. Isto significa que dealguma forma é necessário determinar como os históricos locais são manipuladosquando as páginas são duplicadas, sincronizadas, descartadas ou simplesmentemigradas. O histórico da página é mantido pela cópia local da página e nunca ésincronizada com outras cópias do histórico dessa página que são mantidas em outrosnodos. Se a cópia da página move-se para outra máquina, ou é descartada, o históricolocal é armazenado por algum tempo, aguardando por outra cópia da página. Se talcópia não voltar e o histórico tornar-se muito velho então ele é eliminado.
C) Correção das Decisões do Módulo de Migração
Se threads estão acessando uma página localmente, é possível que nãoexistam informações disponíveis sobre a página (somente informações sobre acessosremotos são registradas). Obviamente, são inevitáveis decisões incorretas de migração.No entanto, como conseqüência de cada decisão errada, mais informações tornar-se-ãodisponíveis, devidos aos acessos tornarem-se remotos e ficarem registrados noshistóricos. Com isso, a próxima vez que um dos nodos transferir threads, suacapacidade de decisão terá aumentado.
O efeito global é um período inicial instável onde threads migramrelativamente freqüentemente e o sistema está ocupado coletando dados sobre osacessos remotos. Idealmente, após algum tempo, o sistema conhece o suficiente sobre ocomportamentos dos acessos à memória, e então uma série de decisões corretas podemser tomadas levando a um estado estável no qual a localidade das referências a páginas éotimizada.
37
Inicialmente, o esquema de seleção de threads é ativado externamente,quando é detectado que existe um desbalanceamento de carga. Isso introduz um novoproblema: situações de ping-pong que são causadas por decisões incorretas podemaparecer mesmo quando a carga está completamente balanceada. Já que ping-pongcausa um alto overhead, deverá ser tratado prontamente, através de um mecanismoadicional.
4.2.3 Tratamento de Ping-Pong
O mecanismo de tratamento de ping-pong é responsável por detectar ecorr igir decisões erradas do escalonador de threads. Quando uma situação de ping-pong é detectada, o módulo de tratamento de ping-pong usa o histórico da páginacorrespondente (da cópia que reside no nodo que detectou) para determinar quais nodosfazem parte de ping-pong, isto é, quais threads estão acessando freqüentemente amesma cópia da página. É inicializado um protocolo que determina qual nodo podeacomodar todas as threads envolvidas no ping-pong. Se tal nodo for encontrado, todasas threads migram e são modificadas para evitar a repetição das decisões que resultaramno ping-pong. Se não for encontrado um nodo, outros mecanismos são aplicados com oobjetivo de reduzir o overhead e estabili zar o sistema (subseção C).
A) Detecção de Ping-Pong
Cada vez que ocorre um acesso a página remota, o módulo de tratamento deping-pong é invocado. Considerando que alguma thread local tente usar uma páginaremota P. O módulo de ping-pong armazena informações sobre o acesso no histórico deP e no histórico da thread e examina o histórico de acessos remotos a P. Se o númerototal de entradas e saídas de P de/para o nodo exceder um certo nível (threshold), omódulo verifica uma situação de ping-pong, de acordo com os critérios:
1) Threads locais tentam acessar a página pouco tempo após deixar onodo, indicando acesso freqüente;
2) A página deixa o nodo pouco tempo depois de chegar, indicandofreqüente acesso por threads remotas.
B) Determinar para Onde Migrar
O objetivo é selecionar um nodo para onde todas as threads participantes noping-pong detectado possam ser transferidas. A seleção do nodo não pode ser realizadalocalmente no nodo que detectou o ping-pong, pois os nodos participantes teminformações diferentes (locais) e podem tomar decisões diferentes em relação ao mesmoping-pong. Além disso, um nodo pode ter informações incompletas ou desatualizadassobre os outros participantes. Pode também não saber quantas threads do outro nodoestão usando a página. Finalmente, mais de uma página poderia estar envolvida no ping-pong, e selecionar o mesmo nodo para todas poderia afetar o balanceamento de carga.Ping-pongs são manipulados de forma centralizada por um Servidor de Ping-Pong, quecoleta toda a informação necessária sobre cada ping-pong, resolvendo então um de cadavez.
38
Cada nodo contém um módulo de tratamento de ping-pong chamadoCliente de Ping-Pong, que inicia um protocolo de resolução de ping-pong quandodetecta uma situação de ping-pong ou quando recebe uma mensagem de ping-pong doservidor de ping-pong. Quando o protocolo de ping-pong para uma página P é iniciado,o cliente examina o histórico da página P para determinar o conjunto de threads queestão utili zando-a e o correspondente conjunto de nodos. O cliente envia umamensagem contendo o número de threads locais que estão usando P, um flag indicandose são ou não migráveis e uma lista de nodos conhecidos para serem participantes doping-pong. Uma vez que o nodo pode comunicar-se somente com alguns nodosenvolvidos no ping-pong, a lista de participantes que está localmente disponível nãoestá necessariamente completa.
Quando o servidor recebe a primeira mensagem com uma situação de ping-pong detectada, envia uma requisição para cada nodo mencionado na mensagem. Oservidor continua coletando informações até que informações atualizadas de todos osnodos envolvidos tenham sido recebidas. Se o número de threads envolvidas for inferiora um certo nível, o servidor seleciona um nodo que a carga esteja baixa o suficiente paraacomodar todas as threads envolvidas. De outra forma, o servidor pode decidir porabortar o tratamento e tentar manter o balanceamento de carga e evitar o overheadadicionado pela migração.
C) Tratamento de Ping-Pong quando Migração é Impossível
Transferir todas as threads que estão usando uma página P para o mesmonodo pode causar comportamento instável no sistema. O exemplo mais simples desseproblema é descrito na figura 4.1. Em cada nodo existe um conjunto de threads usandoos mesmos dados (que não são usados por outras threads). Existe uma thread que usaambos os conjuntos de dados. Se essa thread for permitida migrar cada vez que umping-pong de página é detectado, um ping-pong de thread irá ocorrer.
FIGURA 4.1 – Efeito ping-pong
39
Situações instáveis também ocorrem quando em algum ponto da execuçãoda aplicação um grande número de threads referenciam a mesma página. Essas threadspoderiam ser mantidas em vários nodos ou reunidas em um mesmo nodo (adicionandooverhead e violando o balanceamento de carga). Em ambos os casos um comportamentoinstável irá ocorrer. No primeiro pela detecção do ping-pong ou devido aoescalonamento tentar redistribuir a carga pouco tempo depois da migração no segundocaso.
Vários mecanismos podem ser aplicados para manter o sistema estável.Primeiro, uma vez que uma thread migrou, ela fica proibida de migrar por algumtempo. Segundo, o número total de migrações de ping-pong é limitado por thread.Terceiro, o número de threads que são permitidas migrar para resolver um ping-pong élimitado. Finalmente, quando um ping-pong não puder ser resolvido, overhead decomunicação e instabili dade podem ser tratados bloqueando a página relacionada poralgum intervalo configurável de tempo após recebê-la, de modo que as threads possamacessá-la localmente por um tempo até que seja enviada novamente.
4.3 Corre lation Tracking
Redes de estações de trabalho caracterizam-se pela natureza dinâmica deseus recursos. Tais ambientes são bem explorados por aplicações que podem serreconfiguradas dinamicamente [THI 99]. O artigo escrito por Thikikamol e Keleher[THI 99] explora mecanismos e políticas que permitem reconfiguração dinâmica dasaplicações através de migração de threads. A redistribuição de threads é baseada nocomportamento de compartilhamento de memória. O sistema obtém informaçõescompletas de compartilhamento através de uma fase de “ correlation-tracking”(identificação de corre lações). Estas informações são utili zadas para avaliar acomunicação exigida para um determinado mapeamento de threads e para prever osresultados de desempenho.
4.3.1 Ambiente de Execução
Arquiteturas distribuídas caracterizam-se pela distribuição, heterogeneidadee mudança das capacidades dos recursos. Aplicações paralelas e distribuídas podemexecutar nesses ambientes, mas normalmente não tão efetivamente como nosmultiprocessadores com memória compartilhada. Em parte, isso ocorre devido a essasarquiteturas não serem dedicadas, forçando as threads da aplicação paralela acompetirem com outras tarefas por recursos.
Foi desenvolvido um mecanismo de reconfiguração num sistema de DSM.O sistema DSM utili zado neste trabalho é uma versão do D-CVM (Dynamic CoherentVirtual Machine – Máquina Virtual Coerente Dinâmica), modificado para manipularmigração de threads. D-CVM é um sistema DSM em nível de usuário tendo a páginacomo unidade de coerência, que implementa protocolo de vários escritores econsistência de liberação preguiçosa.
D-CVM implementa reconfiguração através de migração de threads. Comoos sistemas DSM normalmente apresentam maior exigências de comunicação que ossistemas de troca de mensagens, uma boa política de migração de threads para estes
40
sistemas deve considerar também o comportamento da comunicação. Aplicações D-CVM consistem de um único processo e de uma ou mais threads em nível de usuárioem cada nodo do sistema. Cada thread possui uma pilha e outro contexto D-CVM.Todas as threads compartilham os dados globais uniformemente.
4.3.2 Paralelismo e Balanceamento de Carga
Os objetivos principais da proposta de [THI 99] são maximizar oparalelismo, minimizar o desbalanceamento de carga e minimizar a comunicação. Oproblema pode ser decomposto em três tarefas distintas:
1) Determinar o número de nodos que resultará no maior speedup;
2) Minimizar o desbalanceamento de carga ajustando o número de threadspor nodo;
3) Minimizar a comunicação considerando o compartilhamento dos dadospara mapear threads para nodos.
Idealmente, é claro, estas tarefas podem ser executadas ao mesmo tempodevido a elas serem interelacionadas. Uma vez que a quantidade de comunicação podeafetar a eficiência da aplicação, o mapeamento de threads para nodos pode afetar onúmero de nodos para os quais o melhor desempenho é alcançado. Entretanto, endereçartodos estes aspectos simultaneamente pode tornar absurda a complexidade dosalgoritmos.
A) Número de nodos
Determina-se o número de nodos nos quais executar uma aplicação paralelacom o auxílio de um valor inicial fornecido pelo usuário antes de começar a execução.A medida que a aplicação é executada, o sistema verifica a eficiência do processadormedindo a proporção de tempo gasto esperando por comunicação e sincronização. Estaseficiências são comparadas com parâmetros superior e inferior (pontos A e B da figura4.2). No caso da eficiência ser menor que o parâmetro inferior, assume-se que aaplicação poderia obter melhor desempenho executando em mais processadores. Damesma forma, se a eficiência for menor que o parâmetro superior, assume-se que aaplicação poderia obter melhor desempenho executando em menos processadores
FIGURA 4.2 – Curva de speedup
41
B) Capacidade da thread
Um mecanismo de balanceamento de carga deve estar apto a acomodartanto as capacidades heterogêneas dos nodos quanto as threads que executam umaquantidade variável de trabalho. A capacidade do nodo depende da capacidadeintrínseca do nodo, bem como da proporção desta capacidade que é consumida poroutras tarefas. A capacidade residual de um nodo é uma medida dinâmica que pode serdeduzida durante a execução da aplicação. A exigência de recursos da thread tambémpode variar. Esta relação pode ser observada na fórmula, apresentada na figura 4.3. Nafórmula, W i representa a quantidade de trabalho que deve ser atribuída ao nodo i, e Rj
representa a capacidade residual do nodo j . Foram desconsideradas as unidades de W i eRj, considerando que basta apenas a relação de magnitude. Assumindo que existem Nnodos e T threads, então a quantidade de trabalho W i pode ser atribuída para o nodo i écalculada conforme a fórmula apresentada na figura 4.3.
FIGURA 4.3 – Cálculo da quantidade de trabalho
Cabe ressaltar que W i é alguma abstração de trabalho, não necessariamenteo número de threads. Além disso, esta informação ignora a influência da comunicaçãono custo de executar cada parte do trabalho. Esta informação não está disponível seainda não foi realizado o mapeamento de threads para nodos.
4.3.3 Correlação entre Threads
Considerando um par de threads alocadas em nodos distintos, ambasacessando dados na mesma página compartilhada, a comunicação só pode ser evitadamovendo ao menos uma das threads, tal que ambas sejam alocadas no mesmo nodo.Para minimizar a comunicação, o sistema precisa identificar se os pares de threads quecausam a maioria da comunicação não estão alocados no mesmo nodo. A informaçãodeve ser completa, contemplando todas as threads do sistema de forma precisa.
A tarefa de mapear threads específicas para nodos, deveria, idealmente, serrealizada com a utili zação de informações globais. Entretanto, a dependência do estadoglobal introduz novas fontes de overhead no sistema. Contudo, nem todas os processosde decisões tratam bem com informações incompletas ou desatualizadas.
Todavia, são utili zadas informações globais por três motivos. Primeiro, aquantidade do estado necessária para resumir (indicar) o comportamento decompartilhamento para as heurísticas é somente i*n2, onde i é o tamanho de um inteiro en é o número de threads. Esta quantidade de informação pode ser facilmente transmitidaem uma única mensagem para um número realístico de threads [THI 99]. Segundo, asinformações de compartilhamento podem ser transmitidas em conjunto com operaçõesglobais de sincronização existentes. As novas mensagens são somente aquelas que
42
migram threads entre nodos. Finalmente, o mapeamento de threads pode ser utili zadopara adaptar dinamicamente as mudanças no ambiente. Entretanto, a variação na qualdeseja-se obter vantagens é ao menos na escala de dezenas de segundos, nãomilisegundos. O custo de uma única decisão pode, portanto, ser amortizado através deuma relativa grande quantidade de computação.
O objetivo de mapear threads para nodos é minimizar a comunicação.Comunicação ocorre em D-CVM por duas razões: sincronismo e busca de dados. Pode-se considerar que a comunicação pode ser minimizada movendo threads quecomunicam-se para o mesmo (ou próximo) nodo. Uma vez que um sistema tenha umcusto uniforme para os acessos remotos, a comunicação entre pares de threads podesomente será reduzida ou eliminada colocando-as juntas. Alocar todas as threads nomesmo nodo poderá eliminar toda a comunicação, mas presumivelmente não produz omelhor desempenho global.
O custo de comunicação pode ser medido de várias formas. Métricas óbviasincluem contagem de mensagens e quantidade total de dados comunicados. O problemacom essas métricas é que elas refletem somente o compartilhamento entre nodos, nãoentre as threads individuais em cada nodo. Por exemplo, uma grande quantidade decomunicação entre os nodos Ni e Nj não é suficiente para determinar quais threadsdestes nodos estão compartilhando recursos.
Utili za-se as informações do protocolo de DSM para gerar métricas quemedem o compartilhamento entre threads individuais. Dados compartilhados entrethreads podem ser identificados relacionando os acessos à memória compartilhada pelasthreads. Duas threads que freqüentemente acessam as mesmas páginas compartilhadaspodem presumir compartilhar dados. Define-se uma função de densidade como a taxade acessos de uma thread t a uma página p. A correlação de duas threads sobre umapágina p é calculada como o produto das funções de densidade das duas threads para apágina p. A correlação total de duas threads é a soma das correlações para cada páginado sistema [SUD 97].
O sistema utili za o número de páginas compartilhadas entre os nodos comouma forma de prever a quantidade de comunicação que um mapeamento de threads paranodos irá produzir. Foi definida a cor relação de threads como o número total depáginas compartilhadas entre um par de threads. Foi definido um cut cost (custo dedistância) de um determinado mapeamento de threads para nodos como a soma total detodos os pares de threads correlacionados para os quais as threads componentes estãoem nodos distintos. Os custos de distância podem ser utili zados para compararmapeamentos de threads para nodos. Uma vez que o melhor mapeamento estejaidentificado, o ambiente de execução pode migrar todas as threads para sua novalocalização em uma rodada de comunicação. Cabe ressaltar que esta definição pode serestendida para tratar com redes com comunicação não uniforme, multiplicando a relaçãode threads pelos coeficientes específicos dos links.
4.3.4 Mecanismos de Identificação de Correlações
São descritas duas formas de realizar a identificação da correlação entrethreads, um algoritmo passivo, e um algoritmo ativo.
43
A) Identificação Passiva de Correlação
Uma forma de determinar a quantidade de compartilhamento entre threads éidentificar as falhas de página tratadas pelo mecanismo de DSM. Identificando as falhasde página pode-se obter uma estimativa do compartilhamento do sistema. Falhasremotas ocorrem quando threads tentam acessar páginas compartilhadas inválidas.Falhas remotas são resolvidas buscando a última versão da página compartilhada doúltimo nodo que a modificou. O problema é que existe mais de uma thread executandoem cada processador, sendo que essas threads compartilham o mesmo estado. Uma vezque uma thread do nodo tenha validado uma determinada página através de umarequisição remota, todas as outras threads locais podem acessar a página sem invocar osistema de DSM.
Com isso, o sistema obtém somente informações parciais sobre ocomportamento do compartilhamento das threads locais. As decisões de migraçãotomadas com informações parciais podem ocasionar em escolhas erradas, que sãodescobertas após as threads terem migrado para outros nodos. Após a thread termigrado de um nodo, as interações entre essa thread e aquelas que permaneceram nonodo tornam-se visíveis na forma de falhas remotas (a menos que mascaradas por açõesde outras threads no novo nodo). Essas falhas podem ser usadas para identificar threadsque deveriam ser movidas de volta para sua posição original, resultando em um ping-pong das threads (ou thread thrashing) sobre o sistema.
B) Identificação Ativa de Correlação
Identificação Ativa de Corre lação (Active Correlation Tracking) [THI99a] é utili zada para determinar a afinidade ou quantidade de compartilhamento entrepares de threads. Afinidades de threads são combinadas para criar os mapas decorrelação, que resumem o compartilhamento entre todos os pares de threads daaplicação.
Mapas de correlação podem ser utili zados para melhorar o desempenho.Além disso, podem ser usados para estimar o impacto nas exigências de comunicaçãode reconfigurar aplicações em execução através de migração de threads.
Thread-thrashing pode ser evitado se houverem informações sobrecorrelações entre threads locais antes da redistribuição de threads. Essas informaçõessão obtidas através de uma fase de identificação ativa de correlação, que obtém efornece informações completas de correlação para todos os pares de threads, locais eremotas. O algoritmo usa duas estruturas de dados em cada nodo, bits de cor relaçãopor página e bitmap de acesso por thread (figuras 4.4 e 4.5).
1) No começo da fase de identificação, todas as páginas são protegidaspara leitura e é atribuído o valor 1 para o bit de cor relação de cadapágina (figura 4.4(a)). O estado anterior da página é salvo na estruturada página. O escalonador de threads é colocado em um modo especialque evita que a thread perca a CPU até chegar na próxima barreira;
2) A cada falha de acesso a uma página para a qual o bit de correlaçãoesteja com valor 1 (uma falha de correlação), é atribuído o valor 1 parao bit correspondente no bitmap de acesso por thread e é atribuído ovalor 0 para o bit de correlação da página. A página retorna então paraseu estado original e o controle volta para o gerente de falhas de acesso.
44
Se o tipo de acesso tivesse causado uma falha fora da fase deidentificação de correlações, acontece uma falha adicional que é tratadanormalmente (no caso de um acesso remoto);
3) Na próxima barreira, o sistema troca para a próxima thread, atribui 1novamente para todos os bits de correlação das páginas e protege todasas páginas. Esta thread é então liberada para prosseguir. (Repetição dospassos 1 e 2);
4) A fase de identificação acaba quando todas as threads chegarem apróxima barreira. No final da fase de identificação de correlação, éatribuído o valor 0 para todos os bits de correlação e as páginasintocadas retornam a seus estados antigos.
P1 P2 P3 P4 P5 … Pn P1 P2 P3 P4 P5
1 1 1 1 1 … 1 1 0 0 1 0
(a) (b)
FIGURA 4.4 – Bits de correlação por página
Thread i Thread 1
P1 P2 P3 P4 P5 … Pn P1 P2 P3 P4 P5
0 0 0 0 0 … 0 0 1 1 0 1
(a) (b)
FIGURA 4.5 – Bitmap de acesso por thread
Nas figuras 4.4(a) e 4.5(a) pode ser observado o estado inicial das duasestruturas de dados. No caso de uma thread 1, acessar as páginas P2, P3, P5, pode serobservado na figura 4.4(b) que os bits de correlação correspondentes estão com o valor0, e os bits no bitmap de acesso da thread estão com o valor 1 (figura 4.5(b)).
Após a fase de identificação ter finalizado, os bitmap de acesso por threadespecificam exatamente quais páginas cada thread acessou durante a fase deidentificação. Não foi realizada distinção entre acessos de leitura e escrita. O motivo éque alocando dois consumidores de um mesmo dado juntos causa o mesmo benefícioque alocando um par produtor-consumidor. Falhas de página são evitadas em ambos oscasos. A única exceção é que são excluídas páginas que são somente escritas durante ainicialização devido a páginas somente de leitura não causarem tráfego de página.
A fase de traçado apresenta inicialmente duas formas de overhead. O maisóbvio é o custo das falhas de correlação. Este custo aumenta com o número de páginasacessadas localmente, e com o grau de compartilhamento entre as threads locais. Dadoum sistema com n nodos e p páginas, as threads locais irão usualmente acessar nomínimo p/n páginas, mais se existir uma grande quantidade de dados compartilhadosentre as threads. O segundo custo resulta de desabilit ar o escalonador de threads
45
durante a fase de traçado. A ausência do escalonador elimina as vantagens de tolerânciaa latência de multithreading por nodo. O impacto da falta dos mecanismos de tolerânciaa latência é usualmente na ordem de 10-15% [THI 97] e ocorre somente durante a fasede traçado ativo de correlação.
4.3.5 Heurísticas de Mapeamento de Threads
Dado uma mapa de correlações e a capacidade de cada nodo, tenta-semapear threads para nodos de forma a minimizar a comunicação. Deseja-se também,minimizar o número de threads para migrar.
Foram desenvolvidas duas versões para cada heurística: leader-based (comlíder) e leader -less (sem líder ). As heurísticas com líder tentam minimizar a migraçãode threads forçando o líder de cada nodo permanecer no mesmo nodo na novaconfiguração. As threads líderes são aquelas com as menores exigências decomunicação. Se a configuração atual estiver boa, os líderes tendem a prevenir queoutras threads migrem. Os algoritmos com líder funcionam melhor nos casos ondethreads com alta correlação já estão alocadas no mesmo nodo.
A heurística AscEdge tenta garantir que threads com as menores exigênciasde comunicação não serão alocadas no mesmo processador. AscEdge trata threads e ocompartilhamento entre elas como nodos e conexões de um grafo de custos,respectivamente. São mapeadas threads para processadores ordenando as conexões deacordo com o custo (correlação entre as threads) em ordem ascendente. Asextremidades de cada conexão são alocadas em nodos distintos, se possível. Cadathread é alocada no nodo com o qual a thread possui maior correlação (com as threadsjá alocadas no nodo). Nodos são preferidos em ordem numérica no caso de empates.Um problema potencial é que mesmo que as conexões com maior custo sejamprocessadas depois, podem ser alocadas em nodos distintos, causando grandequantidade de comunicação.
DesEdge é similar a AscEdge, exceto que as conexões são processadas emordem inversa, e as threads alocadas no mesmo nodo, se possível. Essa variaçãomanipula as conexões com altos custos de comunicação explicitamente, diferente deAscEdge que manipula implicitamente.
DesNode trabalha diretamente com threads. Threads são ordenadas pelasexigências de comunicação. Realizando uma analogia com o grafo utili zado nas outrasheurísticas, o custo de uma thread (o nodo do grafo) é o custo de comunicação do canalque separa a thread de todas as outras threads. Threads são ordenadas em ordemdescendente, e são mapeadas para nodos com os quais eles tem a maior correlação.
Embora exista uma grande quantidade de variações entre diferentesaplicações e heurísticas, a configuração gerada pela heurística DesEdge com líderapresentou os melhores resultados. DesEdge com líder minimiza os efeitos defragmentação manipulando primeiro as conexões com maior custo. Além disso, aspropostas com líder auxili am a garantir que nodos são supridos na mesma medida.
46
4.4 Comparação
Os algoritmos de escalonamento de threads no contexto de sistemas DSM,procuram distribuir as threads entre os processadores envolvidos na computação deacordo com a localidade dos dados, evitando assim acessos remotos. Para isso utili zaminformações obtidas do mecanismo de DSM que descrevem o comportamento dosacessos à memória. Ambas as técnicas procuram anexar a comunicação gerada emmensagens já existentes, não aumentando assim o número de mensagens.
RAHM utili za informações parciais sobre os acesso aos dados (coletadosem tempo de execução) para aproximar-se ao comportamento dos acesso à memória daaplicação. RAHM apresenta um tempo inicial onde não possui informações suficientespara a tomada de decisões. Além disso, só registra eventos que exigem comunicaçãoentre nodos. Portanto, inicialmente o mecanismo só possui registro sobre ocomportamento dos acessos remotos à memória, uma vez que não são registrados osacessos às páginas locais. Essas informações só serão registradas quando devido a umamigração, a thread deixar de ser local e continuar acessando à página. Como os acesostornaram-se remotos são armazenas informações. Com esse novo registro o mecanismopode decidir por enviar de volta a thread para o nodo que estava inicialmente.
O mecanismo de correlation tracking trata com mais cuidado os acessos àpáginas locais. Possui um algoritmo de identificação ativa de correlação que possibilit acoletar informações sobre os acessos locais. O sistema obtém informações completas decompartilhamento através de uma fase de “ correlation-tracking” (identificação decorrelações). Estas informações são utili zadas para avaliar a comunicação exigida paraum determinado mapeamento de threads e para prever os resultados de desempenho.
RAHM usa informações locais para decidir sobre o escalonamento,enquanto a técnica de correlation tracking usa informações globais. O RAHM utili zainformações globais apenas quando vai tratar de situações de ping-pong. A utili zação deinformações globais aumenta o tempo para a tomada de decisões, uma vez que precisamser coletadas as informações de diversos nodos. No entanto, a decisão é mais precisa. Autili zação de informações locais para decidir é mais rápida, no entanto não há garantiasobre a correção da decisão. O correlation tracking tenta evitar que ocorra situação deping-pong utili zando informações mais precisas sobre os acessos locais. O RAHM tentadetectar uma situação de ping-pong e então passa a tratá-la.
A solução encontrada pelos mecanismos foi deixar que o algoritmo deseleção de threads realize uma estimativa do ganho que pode ser obtido migrando cadathread individualmente para o nodo destino. Com essa finalidade, o algoritmo deseleção de threads usa uma função heurística que leva em consideração as informaçõesque estão disponíveis sobre o comportamento do acesso à memória das threadscandidatas e o impacto da migração nas outras threads.
47
5 Técnicas de Tolerância à Latência
Este capítulo apresenta técnicas utili zadas para tolerar latência de memória elatência de sincronização em sistemas DSM. A seção 5.1 introduz o assunto. A seção5.2 apresenta multithreading. Na seção 5.3 são descritas as propostas de prefetching emultithreading isoladamente e uma proposta para combiná-las. A seção 5.4 realiza umabreve comparação.
5.1 Introdução
Os sistemas DSM apresentam dois tipos principais de latências que devemser tratadas com o intuito de melhorar o desempenho, a latência de memór ia e alatência de sincronização. Latência de memória diz respeito ao intervalo de tempocompreendido entre o momento no qual um processador iniciou um acesso a um dadocompartilhado até que este acesso seja satisfeito [PIN 96]. Latência de sincronizaçãorefere-se ao intervalo de tempo que um processador permanece sem realizarprocessamento útil esperando por uma operação de sincronização.
Para tolerar a latência de leitura a dados remotos, deve ser separada arequisição do dado da sua utili zação, enquanto deve ser encontrado paralelismo útil osuficiente para manter o processador ocupado nesse intervalo de tempo. As duasprincipais técnicas para realizar isso são prefetching e multithreading [MOW 98]. Adiferença entre ambas é que prefetching encontra o paralelismo dentro de uma únicathread, enquanto multithreading explora o paralelismo entre várias threads.
Para ocultar a latência em uma única thread, a requisição dos dados deve serrealizada suficientemente antes da utili zação dos dados no fluxo de execução. Issorequer a habili dade de prever que dados serão necessários. Por outro lado, a proposta demultithreading divide as transações de leitura, fazendo com que a thread que estava emexecução quando ocorreu a falha de acesso perca o controle da CPU. O controle da CPUpassa para uma outra thread concorrente durante o processamento da requisição remota,mantendo assim o processador ocupado. A thread que estava bloqueada esperando pelarequisição remota volta a executar depois que o acesso à memória seja satisfeito.
Latência de sincronização não pode ser tratada diretamente com a utili zaçãode prefetching. No entanto, é possível tratar latência de sincronização commultithreading, uma vez que no momento que um processador ficou bloqueadoesperando por uma operação de sincronização, o controle da CPU pode ser atribuído paroutra thread.
No contexto de sistemas DSM, a primeira vantagem de prefetching é nãoconsumir threads adicionais simplesmente para ocultar a latência. Isso porque alcançarbons speedups com um grande número de threads é desafiante em sistemas DSM, eportanto, não assume-se que o paralelismo seja abundante [MOW 98]. Por outro lado,as vantagens de multithreading incluem o fato de poder tolerar diretamente latência desincronização e de memória e não necessitar de previsão (e portanto pode manipularcomportamentos de acesso complexos ou imprevisíveis). Ambas as propostas envolvemoverheads no ambiente de execução para realizar previsões ou para executar troca decontexto.
48
5.2 Multithreading
Multithreading é util izado em software DSM para ocultar latência dememória e sincronização. Reduz os custos de requisições remotas executando outrasthreads enquanto a thread corrente estiver bloqueada.
5.2.1 Introdução
O paradigma usualmente assumido na literatura de DSM é de um sistemadistribuído composto de uma única thread por processador. Esse arranjo é simples epermite uma eficiência razoável do processador. Entretanto, sistemas DSMfreqüentemente possuem alta latência de comunicação remota, causando que odesempenho destes sistemas seja dependente da freqüência pela qual as operações desincronização ou requisição de dados ocorrem. Embora, uma parte dessa latência seja dooverhead do software local, a maioria do tempo é perdido na rede e no processamentodo nodo remoto [THI 98].
A latência de requisição pode ser quebrada em overhead de envio local, LS,tempo de envio da requisição, W1, overhead de recebimento remoto, RR, processamentoremoto da requisição, RP, overhead de envio remoto, RS, tempo de envio da resposta,W2, e overhead de recebimento local, LR. O tempo que o processador fica esperandopara receber a resposta da requisição pode ser utili zado para executar uma outra thread(figura 5.1).
FIGURA 5.1 – Diferentes overheads de uma requisição remota
O primeiro ganho de desempenho de multithreading é que várias threadspodem ser usadas para garantir que processamento seja realizado enquanto a threadcorrentemente ativa aguarda por uma requisição remota. Se o nível de multithreadingfor alto o suficiente, várias threads podem ocultar a latência de todas as requisiçõesremotas que não seja o overhead do sistema operacional local. Além disso, essaproposta separa o paralelismo físico do paralelismo lógico. Especificar o número dethreads de uma aplicação independente de qualquer arquitetura em particular, possuivárias vantagens, dentre as quais, independência da arquitetura, facili dade de expressão,balanceamento implícito de carga, e facili dade de geração de código por compiladoresparalelizadores. Multithreading também apresenta várias desvantagens, a maioriarelacionada ao custo de tratar com threads adicionais.
49
5.2.2 Modelo de Programação
Os sistemas DSM normalmente assumem o modelo de programação no qualcada processador do sistema executa uma única thread. A vantagem deste esquema é asimplicidade. Uma única thread por nodo simpli fica a manipulação do escopo dasvariáveis globais da aplicação. Tais variáveis no CVM não são compartilhadas (nãofazem parte do espaço de endereçamento compartilhado). Com uma única thread pornodo, cada thread possui sua própria pilha e seus dados globais. Com várias threads emum único nodo, elas compartilham a mesma visão dos dados compartilhados. Isso éproblemático pois introduz um nível adicional na hierarquia de memória da thread.Portanto, todas as threads alocadas em um determinado nodo compartilham variáveisglobais, enquanto threads alocadas em diferentes nodos possuem cópias distintas.
Nodos multi -threaded adicionam um nível a hierarquia de tempo de acessosà memória, isto é, threads localizadas em um nodo compartilham uma afinidade quenão está presente entre threads alocadas em nodos distintos. Considera-se um exemplono qual uma aplicação de matriz distribui pedaços contíguos de colunas para cadathread. Com somente uma thread por processador, a distribuição beneficia-seautomaticamente de qualquer localidade espacial na computação, pois todas as colunasem um único nodo são contíguas. No caso de multi -thread, cuidados devem ser tomadospara alocar pedaços consecutivos da matriz para threads do mesmo nodo. De outraforma, a localidade explorada por um sistema single-thread não estaria potencialmentepresente no caso de multi -thread [THI 97].
5.2.3 Implementação
O sistema CVM suporta vários protocolos e modelos de consistência dememória. Novos protocolos de memória compartilhada são criados derivando classesdas classes base page e protocol. Somente aqueles métodos que diferem dosmétodos da classe base precisam ser definidos na classe derivada. As rotinas do sistemaDSM chamam o protocolo antes e depois das falhas de página, sincronização e eventosde I/O.
O CVM utili za a chamada mprotec do sistema Unix para controlar oacesso as páginas compartilhadas. Qualquer tentativa de executar um acesso restrito auma página compartilhada gera um sinal sigsegv (violação de segmento). Ocontrolador de sinal sigsegv examina as informações locais para determinar o estadoda página. Se a cópia local é apenas para leitura, o controlador aloca uma página noespaço livre e executa um bcopy para criar um twin. Para finalizar o processo, ocontrolador atualiza o direito de acesso para a página original. Se a página local estiverinválida, o controlador requisita uma cópia do proprietário da página. Se existem avisosde escrita para a página, o processador em falha requisita os diffs correspondentes emparalelo. Todos os diffs necessários são recebidos e aplicados a página de formaordenada através do timestamp.
O sistema CVM foi estendido para suportar serviços de threads não-preemptivas, funcionalidade necessária para ocultar a latência (para permitir que ocontrole da CPU possa ser passado para outra thread). Também foram modificados osserviços de comunicação e sincronização para funcionarem propriamente no ambientemulti -threaded. Já que a arquitetura do CVM obriga a separação dos serviços básicos deDSM das funções específicas do protocolo, modelos de consistência podem ser
50
implementados sem modificações no núcleo do código do CVM. Com isso, asmodificações ficam restritas somente a poucas linhas do código do protocolo deconsistência.
O serviço de threads usa uma política simples para decidir quando trocarentre threads. Uma tentativa de executar uma troca de threads ocorre se a threadcorrente bloqueia-se em uma requisição remota ou quando chega em uma barreira e nãoé a última thread local a chegar. Troca de threads pode ocorrer também como resultadode uma requisição explícita na aplicação através de uma chamada da API do CVM.
Foi modificado o núcleo das rotinas de sincronização do CVM com aintenção de reduzir as exigências de comunicação do ambiente multi -threaded.Operações de barreira foram modificadas, de modo que todas, exceto a última threadlocal irão trocar de thread após chegar a barreira. A última thread agrega todas asmensagens de chegadas locais em uma única mensagem de chegada por nodo.Mensagens de partida da barreira são manipuladas de forma similar.
A mesma idéia foi adaptada no nível da aplicação para suportar operaçõesreduzidas, que de outra forma usariam locks globais. Um modelo comum em programasparalelos é acumular modificações nas estruturas de dados compartilhadas localmente,atualizando as estruturas compartilhadas somente no final da iteração corrente.Adicionando transparentemente multithreading neste tipo de aplicação causa que cadathread local atualize a estrutura de dados compartilhados, resultando em mensagensadicionais (e desnecessárias) de dados e sincronização. Foi adicionado um mecanismode barreira local que permite as threads alocadas no mesmo nodo sincronizarem-se comcada outra. Tal mecanismo pode ser usado pela aplicação para acumular as mensagensde todas as threads locais em uma única mensagem de atualização.
O comportamento das operações de obtenção e liberação devem sermodificadas. Foi implementada uma fila local para cada lock, de modo que váriasobtenções locais resultam somente numa requisição de lock remoto. Threads que tentamobter um lock que já está sendo requisitado localmente são colocadas em uma fila localpor lock. O código da liberação prefere os componentes dessa fila sobre qualquer threadremota, mesmo que a thread remota tenha requisitado o lock antes da thread local.
5.3 Combinação de Prefetching e Multithreading
As técnicas de prefetching e multithreading resultam uma melhorasignificante de desempenho quando aplicadas individualmente em sistemas DSM.Entretanto, podem complementar uma a outra adotando prefetching para ocultar alatência de memória e multithreading para ocultar latência de sincronização.
5.3.1 Prefetching
A idéia do prefetching é usar o conhecimento do comportamento futuro dosacessos para buscar os dados remotos para a memória local antes de serem realmentenecessários. Em prefetching controlado por software são inseridas no código chamadasexplícitas de previsão pelo compilador ou pelo programador. Outra proposta é ter umacamada no ambiente de execução de DSM que automaticamente realize o prefetching.Enquanto a vantagem desta última proposta é não exigir modificações no código fonte,
51
Mowry et al. [MOW 98] indicam que com a inclusão explícita de previsões, o resultadodo prefetching é mais inteligente e agressivo.
Antecipações podem ser classificados como binding ou non-binding. Combinding prefetching, o valor que retorna no acesso de leitura subseqüente é o valor domomento em que a operação de previsão completou. Enquanto binding prefetching éfácil de implementar, possui a propriedade indesejável do valor tornar-se inconsistentese outro processador modificou a mesma posição durante o intervalo entre a previsão eo acesso de leitura. Isto coloca restrições significativas em onde previsões podem serinseridas com segurança. Em contraste, com prefetching non-binding os dados sãomantidos junto ao processador, mas permanecem visíveis ao protocolo de coerência, demodo que os acessos garantem obter a última cópia dos dados. Portanto, a propriedadede non-binding permite ao programador ou compilador a flexibili dade de inserirprevisões mais agressivamente sem preocupar-se com a violação da correção doprograma.
Adicionar suporte de non-binding prefetching ao TreadMarks não é umatarefa trivial, devido a natureza preguiçosa e distribuída do protocolo de consistência.Determinar o conjunto de modificações para uma página em um determinado instante, édifícil no TreadMarks já que os avisos de escrita estão distribuídos entre osprocessadores e somente serão conhecidos no momento da obtenção.
Quando uma operação de previsão é executada, é primeiramente examinadoo conjunto de avisos de escrita que foram propagados ao processador local, afim dedeterminar quais são mais recentes que a cópia local da página. Para cada um dos avisosde escritas, é enviada uma mensagem de requisição de antecipação para os nodoscorrespondentes. Recebendo uma requisição de antecipação, o nodo responde com asmodificações necessárias e protege a página para escrita. Se a página for modificada,um novo intervalo é criado tal que o protocolo de coerência possa distinguir asmodificações realizadas antes e depois da resposta da antecipação. O resultado é que osintervalos, que são baseados nas operações de sincronização, podem ser subdivididosem intervalos menores.
Os dados provenientes do prefetching ficam armazenados numa pilhaseparada (gerenciada pelo coletor de lixo – garbage collector – do TreadMarks), quepode ser considerado como uma cache para as respostas dos diffs remotos. No momentoque a página é realmente acessada, as modificações são aplicadas a página afim deatualizá-la. Se a página foi modificada por outro processador desde a previsão, sãosimplesmente requisitados esses diffs remotos e aplicados a página após seremaplicados as modificações do prefetching.
Foi aplicado o algoritmo de prefetching de Mowry [MOW94] para isolarinstantes de falhas dinâmicas através de técnicas de divisão de laços e para escalonarprevisões suficientemente a frente utili zando pipeline por software.
O overhead de prefetching é gerado pelas transformações nos laços eantecipações desnecessárias. É aumentado também o overhead do sistema DSM, pois asrequisições de antecipações são mais caras de servir do que requisições normais dememória, uma vez que envolve a criação de novos intervalos. No entanto, o resultado dautili zação de antecipação afeta de forma positiva o desempenho, pois diminui o tempode espera por dados remotos.
52
5.3.2 Multithreading
A idéia do multithreading é trocar de uma thread para outra no momento deoperações de longa latência, mantendo o processador trabalhando até que complete aoperação remota. O desempenho de multithreading depende de vários fatores, incluindose existe paralelismo na aplicação tal que uma thread pronta para executar esteja sempredisponível, se o tempo para troca de threads é muito alto e se os efeitos de localidade decompartilhar a mesma parte local da hierarquia de memória são positivos ou negativos.
Multithreading foi implementado no TreadMarks utili zando uma bibliotecade threads chamada Pthreads [LEW 98] e [PRO 99]. O benefício de bibliotecas denível de usuário, como a Ptrhreads, é que as threads de um mesmo processadorcompartilham a mesma imagem da memória. Haverá menos informações de estado aserem salvas no momento de uma troca de contexto e haverá menos overheadmanipulando a porção local da memória compartilhada. Por exemplo, se uma threadbusca uma página para a memória compartilhada local, outra thread pode utili zá-ladiretamente.
Uma troca de threads ocorre quando a thread corrente encontra um eventode longa latência – uma falha de memória remota ou uma operação de sincronizaçãoremota. A thread que foi suspensa não será necessariamente reiniciada imediatamenteapós o evento que ela estava esperando completar. Ao invés disso, essa thread serámarcada como pronta para executar e será potencialmente reiniciada quando a threadcorrente perder a CPU.
Para evitar comunicação desnecessária, as requisições são combinadasquando possível. Para acessos de memória remota, é simplesmente protelado o acessosubsequente para a mesma página até que a mensagem de resposta retorne e a páginaseja validada. Com os locks funciona de maneira similar. Mantendo-se informado sobrequais threads estão enfileiradas esperando por um determinado lock, o lock pode serpassado rapidamente entre as threads do mesmo processador. As requisições de barreirasão combinadas de forma que são coletadas as chegadas localmente de forma quesomente a última thread local que chegou irá gerar uma mensagem remota de chegada.
5.3.3 Combinando Prefetching e Multithreading
Cada técnica pode compensar as deficiências da outra, e talvez ocultar maisainda a latência. Por outro lado, as técnicas podem interferir uma na outra, degradando odesempenho. Permanece o questionamento sobre se existe um real benefício nautili zação destas duas técnicas combinadas sobre sua utili zação isoladamente [MOW98].
Para ocultar a latência de sincronização, multithreading é alternativaescolhida, já que prefetching não trata diretamente desse problema. Para ocultar alatência de memória, a resposta é menos clara, visto que ambas as técnicas podempotencialmente ocultar essa latência.
Uma abordagem seria aplicar multithreading para latência de sincronizaçãoe aplicar prefetching e multithreading para latência de memória. Experimentosrealizados mostraram que mesmo com vários esforços para aumentar o desempenho,não é alcançado melhor desempenho do que utili zando as técnicas isoladamente [MOW98]. O problema é que ficar trocando entre threads tende a resultar num padrão de
53
falhas quebrado, o que torna mais lenta as requisições de rede, incluindo asantecipações. Quando antecipações não conseguem retornar a tempo, ocorre uma novatentativa (já que as antecipações não são confiáveis) seguido por uma troca de thread,portanto exacerbando o problema. Como resultado, tende-se a pagar todo o overheaddas duas técnicas, sem melhoras substanciais no objetivo de ocultar a latência.
Por esses motivos passou a ser considerada uma proposta diferente,aplicando multithreading para latência de sincronização e prefetching para ocultar alatência de memória.
O esquema original de prefetching teve que ser modificado para funcionarem conjunto com multithreading. Já que existe normalmente uma sobreposição detrabalho entre um conjunto de threads executando em um mesmo processador, aprimeira thread que acessa um dado remoto antecipa este dado para as outras threads.Portanto, deve ser evitado que as threads subsequentes realizem antecipaçõesdesnecessárias, mas existem duas complicações: todas as threads executam o mesmocódigo, e não sabem a priori qual thread chegará primeiro ao dado (já que as threadssão escalonadas dinamicamente). Para resolver esse problema, foram identificadoscasos onde threads no mesmo processador poderiam realizar prefetchingredundantemente dos mesmos dados, essas previsões são protegidos com um testecondicional sobre um flag que recebe explicitamente o valor O do primeiro processadorque chegar ao dado.
5.4 Comparação
As técnicas de prefetching e multithreading podem melhorar o desempenhodos sistemas DSM reduzindo o tempo que os processadores permanecem sem trabalhoútil a realizar esperando por requisições remotas.
O paradigma usualmente assumido na literatura de DSM é de um sistemadistribuído composto de uma única thread por processador. Prefetching pode seguiresse padrão. Ao contrário, multithreading não segue este padrão, pois exige mais deuma thread. Os custos de requisições remotas são reduzidos executando outras threadsenquanto a corrente estiver bloqueada. Multithreading tolera latência de sincronização elatência de memória. Uma vez que o primeiro ganho de desempenho de multithreadingé que várias threads podem ser usadas para garantir que processamento seja realizadoenquanto a thread correntemente ativa aguarda por uma requisição remota, se o nível demultithreading for alto o suficiente, várias threads podem ocultar a latência de todas asrequisições remotas que não seja o overhead do sistema operacional local. Além disso,essa proposta separa o paralelismo físico do paralelismo lógico.
Em uma das propostas, a thread que foi suspensa será reiniciadaimediatamente após o evento que ela estava esperando completar. Ao invés disso, naoutra proposta, essa thread será marcada como pronta para executar e serápotencialmente reiniciada quando a thread corrente perder a CPU.
Se a aplicação for desenvolvida independente da arquitetura, com autili zação de várias threads não precisam ser modificadas ou muito pouco modificadaspara executar multithreading.
A idéia do prefetching é usar o conhecimento do comportamento futuro dosacessos para buscar os dados remotos para a memória local antes de serem realmente
54
necessários. Em prefetching controlado por software são inseridas no código chamadasexplícitas de previsão pelo compilador ou pelo programador. Outra proposta é ter umacamada no ambiente de execução de DSM que automaticamente realize o prefetching.Enquanto a vantagem desta última proposta é não exigir modificações no código fonte,Mowry et al. [MOW 98] indicam que com a inclusão explícita de previsões, o resultadodo prefetching é mais inteligente e agressivo. Portanto, as propostas de prefetchingpodem exigir modificações no código fonte.
Nos casos onde prefetching é utili zado para tolerar latência de memória,multithreading poderá complementar (ocultando a latência de sincronização) se asoperações de sincronização ocuparem uma fração significante do tempo de execução.Prefetching e multithreading trabalham melhor em conjunto em software DSM quandomultithreading preocupa-se primeiramente com a latência de sincronização e permite aoprefetching manipular a latência de memória. Cada técnica pode compensar asdeficiências da outra, e talvez ocultar mais ainda a latência. Por outro lado, as técnicaspodem interferir uma na outra, degradando o desempenho. Permanece o questionamentosobre se existe um real benefício na utili zação destas duas técnicas combinadas sobresua utili zação isoladamente.
Qual é a estratégia para tolerar latência em software DSM? Se for difícilprever os endereços de memória com antecedência suficiente para buscar os dados,então multithreading poderá ser a melhor solução. Uma vez que é pago o overhead parasuportar multithreading para ocultar a latência de memória, não existe razão para nãoaplicá-la também para tolerar latência de sincronização. Se os endereços são previsíveiscom a antecedência suficiente para que possa ser efetivamente realizado o prefetching,geralmente prefetching comporta-se tão bem ou até melhor que multithreading paratolerar latência de memória. A melhor proposta para ocultar latências depende defatores como previsibili dade do comportamento dos acessos à memória e a extensãocom a qual a espera pelo lock domina o tempo de sincronização.
55
6 Ferr amentas de Visualização
As ferramentas de visualização auxiliam os sistemas DSM, tornandopossível que o programador possa visualizar graficamente a execução da aplicação,identificando os pontos críticos. A seção 6.1 introduz o assunto. A seção 6.2 apresenta aferramenta PAPP. Na seção 6.3 é descrita a ferramenta Carnival. A seção 6.4 comparaas ferramentas descritas no capítulo.
6.1 Introdução
Vários sistemas de DSM têm sido propostos para facilit ar o processo deconversão de programas seqüenciais existentes para programas paralelos usando omodelo de programação de memória compartilhada. Uma vez que essas aplicaçõesserão executadas em uma arquitetura distribuída surge o problema da latência decomunicação. Portanto, se esses programas não forem cuidadosamente analisados eadaptados para minimizar a comunicação, o desempenho alcançado na maioria doscasos ficará distante ao alcançado com bibliotecas de troca de mensagens. Contudo,ajustar o desempenho das aplicações para DSM poderá exigir tanto esforço doprogramador quanto seria necessário para rescrever o programa utili zando o paradigmade troca de mensagens.
As propostas de Brorsson e Kral [BRO 98] e Meira Jr. et al. [MEI 97]consistem em estudar os efeitos dos acessos à memória compartilhada no desempenhode sistemas DSM. Isso pode ser realizado com ferramentas que mostrem visualmente aextensão pela qual os acessos à memória compartilhada contribuem para o tempo deexecução e associá-los as linhas correspondentes no código fonte. A justificativa emaior motivação para o desenvolvimento desse tipo de ferramenta é que programadoresprecisam de auxílio para conseguir melhor desempenho dos programas.
Sincronização e comunicação permanecem como as maiores fontes dedegradação de desempenho em sistemas DSM. Reduzir ou eliminar sincronização ecomunicação em sistemas DSM é complicado. Comunicação em sistemas DSM sãoditadas por detalhes do protocolo de coerência, e portanto, fora do controle direto dousuário. Como resultado, a relação entre as referências à memória compartilhada nocódigo fonte e a freqüência resultante de invalidações, requisições de página e diffspodem não ser entendidos pelo programador.
Além disso, sistemas DSM suportam o modelo de memória compartilhadaem uma variedade de arquiteturas, onde os custos associados com comunicação esincronização variam bastante. Implicitamente a diferença de custo das várias operaçõesestá embutida no código fonte, e por isso são difíceis de descobrir e de mudar quando ocódigo é portado de uma arquitetura para outra. Outra característica que deve serconsiderada ainda é a natureza dinâmica de sincronização e comunicação torna difícilassociar overheads de tempo de execução com estruturas de dados ou segmentos decódigo específicos. Freqüentemente o custo de uma operação é distribuída no tempo(uma operação de escrita em um processador causa uma invalidação em outro, massomente no ponto de sincronização) e no espaço (uma requisição de um processadordeve ser satisfeita por outro, tornando difícil entender a causa de overheads excessivosobservados durante a execução).
56
As ferramentas de visualização propõem-se a preencher essa lacuna,fornecendo auxílio visual para que os programadores observem a execução daaplicação, considerando o tempo no qual o processador esteve ocupado, desocupado, emcomunicação, esperando.
6.2 PAPP
Esta seção apresenta a proposta de Brorsson e Karl [BRO 98] de umaferramenta para visualizar a execução de um programa de forma a destacar os gargalosde desempenho. A ferramenta associa os gargalos identificados as linhascorrespondentes no código fonte com o intuito de determinar que partes do código são acausa da perda de desempenho.
O TreadMarks precisou ser modificado para executar as medições de tempoda execução e para registrar os eventos que causam comunicação entre processos. Parareduzir o impacto de registrar a execução, a análise é adiada tanto quanto possível parauma fase posterior. A análise corrente do registro da execução é provocada pelasoperações de barreira e é por esta razão que são registrados somente programas queutili zam barreiras para sincronização entre processos. A análise e visualização daexecução é realizada por uma ferramenta chamada PAPP (Programer’s Aid for ParallelProgramming).
A tela de visualização no PAPP é baseada em um diagrama de espaço-tempo, mostrando o tempo de execução para cada processador dividido em intervalos debarreiras. Cada intervalo de barreira é subdividido em tempo ocupado, tempo deobtenção de lock, tempo de obtenção de dado compar tilhado, tempo de interrupçãode I /O e tempo de overhead. O foco é o tempo de aquisição de dados que pode serrelacionado com acessos de escrita do intervalo de barreira anterior. O log de execuçãocontém informações sobre onde estes acessos de escrita foram executados e a PAPP nãosomente fornece a possibili dade de indicar gargalos de desempenho, mas também indicadiretamente as fontes desses acessos de memória, que de outra forma seriam muitodifíceis de serem encontrados.
6.2.1 Interface do Usuár io
A figura 6.1 mostra a janela de interface do usuário para visualizar aexecução de uma aplicação no TreadMarks. O janela de visualização mostra uma linhade tempo para cada processador dividida em intervalos. Os intervalos são criados comas operações de barreira. Para cada intervalo, o tempo de execução é subdividido emtempo ocupado e vários outros overheads, conforme a legenda mostrada na figura 6.2.Para os propósitos desse trabalho, os overheads mais importantes são:
� Tempo obtendo dados compartilhados – quando um processadorrequisita e espera pelos diffs de outros processadores;
� Tempo de I /O – quando um processador é interrompido para servirrequisições de outros processadores;
� Tempo desocupado (idle) – quando um processador está esperando porum ou mais processadores chegarem a barreira.
57
A extensão de cada intervalo é proporcional ao tempo de execução. Oprogramador pode facilmente obter uma visão da execução do programa identificandoquais intervalos consomem mais tempo e onde existem overheads de acesso à memória.
FIGURA 6.1 – Janela de Visualização da PAPP
FIGURA 6.2 – Legenda de cores da PAPP
A partir dessa tela inicial, o usuário pode selecionar um determinadointervalo e passar a visualizar somente esse intervalo (figura 6.3). Quando o usuárioseleciona no campo vermelho dentro de um intervalo (conforme mostra a partesobreposta da figura 6.3), uma janela aparece com a lista de instruções que causaramcomunicação nesse intervalo. Essa lista consiste de operações de armazenamento queem intervalos anteriores escreveram em páginas acessadas nesse intervalo. A lista éordenada de acordo com o tempo para transmitir o diff correspondente.
Se a mesma instrução acessar páginas diferentes, o tempo de transmissãopara o diff de cada página é acumulado. Para cada instrução é mostrado o valor docontador de programa, juntamente com o número de acessos que a instrução realizou, otamanho total de todos os diffs associados com a instrução e finalmente o tempo total detransmissão.
58
FIGURA 6.3 – Análise de um intervalo específico
Quando o usuário seleciona uma instrução da linha, uma janela aparece como número da linha, o nome do procedimento e o arquivo onde a linha de código quegerou a instrução está localizada. A janela com a lista de instruções e janela com alocalização da instrução podem ser vistas na figura 6.3. Estas informações são usadaspelo programador para localizar gargalos de desempenho e entender o que no programaestá degradando a execução.
6.2.2 Coleta dos Dados
Existem dois tipos de informações que são necessárias no PAPP. Asmedidas de tempo para produzir a janela de visualização e informações sobre escritasem dados da memória compartilhada para poder associar escritas que degradam odesempenho as linhas do código fonte. Estas informações são coletadas pelo ambientede execução e armazenadas em um arquivo para serem analisadas posteriormentedurante o processamento da barreira, tal que o distúrbio na execução dos processadoresé o menor possível.
Um intervalo termina e o próximo começa quando termina uma operação debarreira. O tempo de execução do intervalo é em boa parte tempo de processamento(tempo ocupado), mas também inclui tempo para aquisição de lock, falhas de segmento(SEGV), processamento de interrupção de I/O (Sigio), tempo para analisar o código eoutros overheads, conforme resumido na tabela 6.1. Esses overheads foram medidosseparadamente e deduzidos do tempo entre duas barreiras para obter o tempo realmenteocupado. O overhead do PAPP consiste do tempo para processar o traçado do código eo tempo para escrever o arquivo de saída.
59
TABELA 6.1 – Overheads identificados
Componente no Tempode Execução
Comentário
Ocupado O processador está realizando trabalho útil
Obtendo lock Processamento de lock e espera para obter um lock
Barreira Processamento de uma operação barreira
SigioProcessamento de interrupção de I/O enquanto oprocessador estivesse ocupado
Obtendo dado compartilhadoProcessamento da falha de acesso remoto e espera daresposta da requisição do dado compartilhado
Idle (desocupado)Esperando que os outros processadores alcancem abarreira
Overhead da PAPP Overhead de realizar as identificações e medições
6.3 Carnival
Carnival [MEI 97] é uma ferramenta de análise e medida de desempenhoque auxili a o usuário a entender o desempenho dos protocolos e das aplicações DSM. Apartir dos registros da execução do programa, o Carnival apresenta dados dedesempenho como uma hierarquia de perfis de execução. Durante a análise, Carnivalrealiza o processo de inferência que relaciona fenômenos de desempenho as causasespecíficas no código fonte ou no protocolo de DSM. Para isso utili za técnicas queenfocam em duas fontes importantes de overhead em sistemas DSM: a análise detempo em espera identifica as causas de overhead de sincronização e produz umaexplicação para cada fonte de tempo em espera no programa; a análise de comunicaçãoidentifica a seqüência de requisições que resultam em invalidação e produz umaexplicação para cada fonte de comunicação. Essas técnicas, as quais foramimplementadas como parte da ferramenta de visualização de desempenho Carnival,podem ser utili zadas para entender o desempenho da aplicação e melhorar aimplementação.
6.3.1 A Ferramenta
Carnival é uma ferramenta de análise e medição de desempenho que suportaabstração hierárquica na apresentação dos dados de desempenho, mantendo links entreas medidas e o código fonte e automatizando a análise causa-efeito dos fenômenos queafetam o desempenho. A análise de desempenho com o Carnival consiste de quatropassos: (1) instrumentação, (2) execução do programa, (3) análise automática, e (4)visualização.
Durante a fase de instrumentação, um pré-processador utili za informaçõesestáticas [MEI96] ou sugestões do usuário que identificam as partes do código onde acomputação é replicada. São inseridas chamadas de instrumentação no código daaplicação. Cada chamada registra a ocorrência de um evento importante, um timestamp
60
e o bloco básico (ou estrutura de dados) no código fonte onde o evento ocorreu. Ocódigo instrumentado é ligado a biblioteca que gera eventos em um arquivo de tracequando aplicação é executada. Após a execução, o pré-processador do Carnival analisaos arquivos de trace, produzindo uma hierarquia de perfis de desempenho e explicaçõespara os vários fenômenos de desempenho.
A biblioteca de instrumentação é o único código dependente de arquiteturado Carnival. Para usar a ferramenta Carnival com TreadMarks, foi necessárioimplementar um relógio global dentro do TreadMarks (para gravar os timestamps) edefinir os eventos do protocolo que seriam relevantes para a análise. O relógio globalfoi implementado enviando um broadcast do valor do relógio de um dos processadores.
Os eventos relevantes do TreadMarks incluem operações de lock, barreiras,requisições de página e coleta de lixo. A nível da aplicação são armazenados dois tiposde computação: computação paralela representa código paralelizado executado por cadaprocessador em dados diferentes; computação replicada representa a execuçãoredundante em cada processador como efeito colateral da paralelização. O tempo gastodurante a execução é dividido em quatro categorias para análise: (1) computação, (2)tempo idle (tempo em espera), (3) overhead local do protocolo, e (4) overhead dodaemon causado por requisições remotas satisfeitas localmente.
6.3.2 Análise do Tempo em Espera
Vários overheads associados ao paralelismo em última análise manifestam-se como tempo em espera. Um processador está idle enquanto espera por outro. Tempoem espera pode ser introduzido em qualquer ponto de sincronização ou se umarequisição é realizada por um processador e é servida por outro (e.g., falhas de páginasservidas remotamente).
Considerando dois processadores A e B que sincronizam-se em umabarreira, executam por um período de tempo e sincronizam-se novamente na barreira.Assumindo que A chega na barreira antes de B. Pode ser definida a causa do tempo emespera sofrido por A, a diferença nos caminhos de execução dos processadores A e Bdesde a última vez que eles sincronizaram-se em uma barreira. Para tornar mais claroporque A deve esperar por B, são comparados os caminhos de execução dosprocessadores e determinado porque um caminho é mais longo do que o outro. Todas ascoisas que os dois caminhos tinham em comum foram removidas, deixando de ser umacausa potencial do tempo em espera. Permaneceram somente as diferenças entre os doiscaminhos como uma explicação do tempo em espera. Estas diferenças podemrepresentar segmentos de código que foram executados por um processador mas não poroutro, ou operações de comunicação que foram requeridas por um processador mas nãopelo outro.
A análise do tempo em espera é uma técnica automatizada que geraexplicações para tempo em espera em uma execução [MEI96]. A implementação analisaos arquivos de trace da execução, gravando cada ocorrência de tempo em espera e oconjunto de blocos básicos percorridos por cada processador para chegar ao ponto desincronização. O resultado desse processo é (i) um perfil global do tempo de execuçãodo programa, que descreve quanto tempo foi destinado as várias formas de overhead(e.g., desbalanceamento de carga, contenção, paralelismo insuficiente) que resultaramem processadores idle; (ii ) um perfil de tempo em espera para cada bloco básico noprograma, que auxili a a identificar partes do código fonte que mereçam atenção
61
especial; e (iii ) uma explicação para cada fonte de tempo em espera em termos deblocos básicos que devem ser modificados para reduzi-los.
No TreadMarks, processadores podem tornar-se idle enquanto executamalguma das quatro operações: (1) obtenção de lock, (2) barreira, (3) requisição dediff /página, e (4) coletando lixo.
A análise de tempo em espera foi implementada no Carnival usando trêsferramentas independentes. A primeira ferramenta busca informações no arquivo detrace e produz como saída um par de caminhos de execução para todas as instâncias detempo em espera na execução. Cada par de eventos combinados (tais como começo e ofim de uma chamada a biblioteca TreadMarks) torna-se um passo de execução que éidentificado pelo processador onde o evento aconteceu, a categoria e a localização nocódigo fonte, e tem a duração associada com ele. Um caminho de execução é umconjunto de passos de execução, tal que o tamanho é obtido pelo produto processadoresx estados x blocos básicos.
Outra ferramenta recebe como entrada a lista de passos de tempo em esperae o par de caminhos representando cada passo, e cria um conjunto de classesequivalentes de caminhos de execução (i.e., incorpora caminhos equivalentes). A saídadessa ferramenta é uma lista de passos de tempo em espera em termos de caminhosrepresentativos para uma classe equivalente. O passo de tempo em espera define aduração da espera. O caminho representativo define o percentual da duração associadacom cada passo da execução do caminho.
Finalmente, para cada instância de tempo em espera, outra ferramentaremove qualquer passo redundante entre um par de caminhos. Essa ferramenta tambématua como um filt ro no conjunto de caracterizações, permitindo ao usuário selecionarpassos individuais da execução para a análise
6.3.3 Análise da Comunicação
Em sistemas DSM, comunicações ocorrem quando uma página é acessadapor um processador e a página não está disponível localmente. A página pode não estardisponível porque (i) é a primeira referência a página (início frio – cold start) ou (ii ) apágina foi invalidada como conseqüência de operações de escrita em outro processadorem um subseqüente ponto de sincronização. Para poder entender porque uma referênciaa página resulta em uma requisição remota, devem ser conhecidas as operações queprecederam a requisição (e.g., leituras, escritas, invalidações). A ordem e o tipo deoperações em uma página que precedem uma requisição remota são a causa darequisição remota.
A análise de comunicação examina as causas das requisições remotas e apartir dessas informações infere o padrão de acessos exibido por uma página ou linha decódigo. Os padrões de acesso são: (i) único produtor – único consumidor, (ii ) (i) únicoprodutor – vários consumidores, (iii ) vários produtores – único consumidor, (iv) váriosprodutores – vários consumidores, (v) migratório, e (vi) início frio.
Para inferir esse padrão de acessos, a análise de comunicação usa traces daexecução do programa que contém um registro de todas as falhas de página e operaçõesde sincronização, com um timestamp global para cada. Cada falha de página armazena alinha de código que gerou a falha, a natureza da falha (leitura ou escrita) e o número dapágina. Cada operação de sincronização armazena a lista de páginas que foram
62
invalidadas como parte da operação. A partir destes traces, a causa imediata de cadarequisição remota é determinada automaticamente, onde uma causa imediata é ainvalidação que precede a falha de página, e o acesso (falha) de escrita que gerou osavisos de escrita no ponto de sincronização.
Requisições para uma determinada página são normalmente encadeadas(i.e., uma falha de página é a causa de outra que acontece depois no tempo),correspondendo a migração de página entre processadores. A causalidade entrerequisições para uma página é representado como um grafo direcionado, chamado deGrafo de Comunicação. Este grafo é construído para cada página enquanto o arquivode trace é analisado sendo determinadas as causas imediatas para falha de página.
Os nodos do grafo representam as falhas de página (e sua causa imediata) eos arcos representam a causalidade dos relacionamentos. Existe um arco entre doisnodos se a falha de escrita explicada por um nodo gera um aviso de escrita que é umacausa imediata para a falha no outro nodo. É atribuído um peso para os arcos de acordocom o custo cumulativo das operações de comunicação que o arco representa. Se aintenção for entender porque aconteceu uma falha em uma página que o processador jápossuiu no passado, volta-se no grafo através dos arcos até chegar a um nodorepresentando a falha anterior no mesmo processador.
A saída desse processo é, para cada estrutura de dados, uma lista deconjunto de grafos que fornecem explicações para as falhas de página daquela estrutura.Cada conjunto de grafos representa uma ou mais páginas que comportam-se de formasimilar. Essas operações são aumentadas com perfis de comunicação, que descrevemcomo os custos de comunicação são distribuídos entre as linhas de código fonte,estruturas de dados e padrões de acesso que resultam em uma requisição de página, eportanto, é possível descobrir otimizações no layout dos dados ou escalonamento paramelhorar o desempenho.
É importante ressaltar que a comunicação é uma fonte de tempo em espera,e portanto, contribui no overhead do processador que executa a comunicação e emalgum outro processador que deve esperar para que a comunicação acabe. Com isso,reduzindo a quantidade de comunicação pode ter o benefício de reduzir o tempo emespera, de modo que o tempo melhorado durante a execução deverá ser maior que omedido pelo tempo de comunicação.
Requisição de páginas e de diffs são as operações do TreadMarks foco daanálise de comunicação, que também é implementada com três ferramentas. A primeiraferramenta recebe como entrada um trace contendo todos os eventos relacionados e apágina (falhas de página, requisição de diffs, invalidações) e mantém um registro porpágina da última operação que afetou a página em cada processador. Quando aferramenta encontra uma requisição no trace, apresenta na saída um sumário darequisição (i.e., processador, localização no código fonte, tempo para satisfazer) e suacausa, que é definida como a localização da invalidação e a informação precedente deacesso de escrita (i.e., processador e localização no código fonte).
Outra ferramenta recebe como entrada o sumário das requisições de páginae suas causas, e cria para cada página, um grafo de causalidade, onde os nodos sãoposições do código e os arcos são as relações causais. Existe um arco de um nodo paraoutro se a posição fonte (bloco básico) associada com o primeiro nodo causou uma falhade acesso na posição fonte associada com o segundo nodo. Os nodos e os arcospossuem atributos. Os nodos descrevem o conjunto de processadores que leram ouescreveram na página, e o padrão de acessos exibido. Os arcos contém os custos
63
cumulativos da requisição e a localização da operação de sincronização que produziu ainvalidação.
A última ferramenta cria um banco de dados de grafos de causalidade, queresumem o padrão de acessos do programa e as causas das referências as páginasremotas. O grafo de causalidade do programa é reunido com os grafos de causalidadedas páginas que são similares em termos de padrões de acesso e causas. Esta últimaferramenta também cria a interface de visualização para examinar o padrão de acessospara as estruturas de dados e conjunto de páginas.
6.3.4 Visualização de Desempenho com Carnival
Carnival apresenta perfis de desempenho e análise de tempo em espera nocontexto do código fonte. Isso auxili a o usuário a identificar facilmente no código fonteonde o programa gasta a maioria do seu tempo de execução, e onde no códigoimportantes fontes de overhead paralelo são introduzidos.
A primeira janela de visualização do Carnival (figura 6.4a) é dividida emduas partes. O código fonte (com o número da linha) é apresentado na direita.Informações sobre cada escopo no código fonte aparece na esquerda. Os números daslinhas são apresentados em tons de cinza, onde a intensidade representa o percentual dotempo de execução (somado entre todos os processadores) gasto em determinada linhado código. Assim, os usuários podem facilmente localizar no código fonte onde amaioria do tempo foi gasta.
FIGURA 6.4 – Janela de visualização do Carnival
Duas janelas pop-up são usadas para análise de tempo em espera. O MapaWT (figura 6.4b) fornece uma perspectiva global de todas as fontes de tempo em
64
espera. O Mapa de Caracter ização (figura 6.4c) apresentam a explicação para umúnica fonte de tempo em espera em termos dos dois caminhos de execução envolvidos.
O Mapa WT lista cada fonte de tempo em espera, o número da linha na qualocorreu a espera, o nome do escopo envolvido e o percentual sobre o tempo total detempo em espera associado com o escopo. A barra de cores indica a natureza dosoverheads que estão causando o tempo em espera no escopo, tal comodesbalanceamento de carga (LI ), paralelismo insuficiente (IP), comunicação econtenção (CC). Este mapa é utili zado para navegar na janela do código fonte. Clicandoem uma entrada no Mapa WT causa que a janela principal de visualização se desloquepara a parte relevante do código fonte e o Mapa WT apresenta estatísticas sobre cadacausa de tempo em espera. Estas estatísticas incluem o percentual de contribuição decada causa para o tempo total de tempo em espera, bem como o total de tempo emespera explicado por cada causa.
Selecionando em uma caracterização no Mapa WT produz uma explicaçãopara o tempo em espera no Mapa de Caracterização. As operações codificadas com autili zação de cores para o mais longo dos dois caminhos são apresentados no ladodireito da janela. O número de ocorrências para cada operação é dada, como opercentual de tempo em espera associado com cada escopo. Selecionando em umescopo desloca a janela para a parte relevante do código.
6.4 Comparação
Ambas as propostas procuram por pontos do programa onde houve perda detempo, ou seja, o processador ficou parado esperando por uma requisição remota. Essespontos são mostrados graficamente e é possível selecioná-los para obter mais detalhes,dessa forma facilit ando a correção do problema.
As duas ferramentas são util izadas para visualizar o desempenho deaplicações que executam no ambiente de execução do TreadMarks. O TreadMarksprecisou ser modificado para executar as medições de tempo da execução e pararegistrar os eventos que causam comunicação entre processos na PAPP. Para usar aferramenta Carnival com TreadMarks, foi necessário implementar um relógio globaldentro do TreadMarks (para gravar os timestamps) e definir os eventos do protocolo queseriam relevantes para a análise.
Existem dois tipos de informações que são necessárias no PAPP. Asmedidas de tempo para produzir a janela de visualização e informações sobre escritasem dados da memória compartilhada para poder associar escritas que degradam odesempenho as linhas do código fonte. Estas informações são coletadas pelo ambientede execução e armazenadas em um arquivo para serem analisadas posteriormentedurante o processamento da barreira, tal que o distúrbio na execução dos processadoresé o menor possível.
PAPP analisa somente aplicações que utili zam barreiras para realizar asincronização entre processos, isso porque o tempo total de execução é dividido emintervalos de acordo com as operações de barreira. O Carnival não possui essalimitação.
Durante a análise, Carnival realiza o processo de inferência que relacionafenômenos de desempenho as causas específicas no código fonte ou no protocolo de
65
DSM. Para isso utili za técnicas que enfocam em duas fontes importantes de overheadem sistemas DSM: a análise de tempo em espera identifica as causas de overhead desincronização e produz uma explicação para cada fonte de tempo em espera noprograma; a análise de comunicação identifica a seqüência de requisições que resultamem invalidação e produz uma explicação para cada fonte de comunicação. A análise dedesempenho com o Carnival consiste de quatro passos: (1) instrumentação, (2) execuçãodo programa, (3) análise automática, e (4) visualização.
Os eventos relevantes do TreadMarks incluem operações de lock, barreiras,requisições de página e coleta de lixo. A nível da aplicação são armazenados dois tiposde computação: computação paralela representa código paralelizado executado por cadaprocessador em dados diferentes; computação replicada representa a execuçãoredundante em cada processador como efeito colateral da paralelização. O tempo gastodurante a execução é dividido em quatro categorias para análise: (1) computação, (2)tempo idle (tempo em espera), (3) overhead local do protocolo, e (4) overhead dodaemon causado por requisições remotas satisfeitas localmente.
A tela de visualização no PAPP é baseada em um diagrama de espaço-tempo, mostrando o tempo de execução para cada processador dividido em intervalos debarreiras. Cada intervalo de barreira é subdividido em tempo ocupado, tempo deobtenção de lock, tempo de obtenção de dado compartilhado, tempo deinterrupção de I /O e tempo de overhead. O foco é o tempo de aquisição de dados, oqual pode ser relacionado com acessos de escrita do intervalo de barreira anterior.
66
7 Conclusão
Este trabalho apresentou várias técnicas que procuram melhorar odesempenho de sistemas DSM, aproximando o desempenho desses sistemas com oalcançado por bibliotecas de troca de mensagens.
O suporte de compilação é importante para realizar uma análise preliminardo código fonte da aplicação e possibilit ar que otimizações sejam realizadas durante aexecução, aumentando o desempenho. O suporte de compilação para o TreadMarksadiciona no código fonte primitivas que procuram antecipar os dados que serãoacessados, agregar comunicação e substituir operações de barreira por sincronizaçãoponto-a-ponto. O suporte de compilação para o CVM altera o código fonte da aplicaçãorealizando as otimizações determinadas pelo compilador.
As técnicas que adaptam dinamicamente a granularidade da unidade decoerência com o comportamento do compartilhamento da memória procuram evitar ofalso compartilhamento. A técnica apresentada por Amza aumenta o tamanho daunidade de coerência múltiplas vezes o tamanho da página da memória virtual deacordo com um algoritmo de agregação dinâmica. O Adaptable View varia agranularidade de compartilhamento de grãos finos (compartilhamento em nível devariável) à grãos grossos (compartilhamento em nível da página da memória virtual),podendo possuir tamanhos intermediários.
Os mecanismos de escalonamento de threads para sistemas DSM funcionamem conjunto com mecanismos que identificam o comportamento dos acessos à memóriacompartilhada. Os algoritmos de escalonamento de threads utili zam as informaçõessobre o compartilhamento das páginas para distribuir as threads entre os nodosbuscando a localidade dos acessos a memória. O mecanismo RAHM apresenta umoverhead menor pois registra apenas os eventos que exigem comunicação. Já omecanismo Correlation Tracking possui uma fase de identificação ativa de correlaçãoque influencia de forma mais direta no funcionamento do sistema.
As técnicas de tolerância à latência, prefetching e multithreading, reduzem otempo que o processador fica sem trabalho útil a realizar. Multithreading conseguetolerar tanto a latência de memória quanto a latência de sincronização. Já a técnica deprefetching tolera apenas latência de memória. A proposta de combinar prefetching paratolerar a latência de memória e multithreading para tolerar a latência de sincronizaçãoapresenta desempenho semelhante a aplicação das técnicas isoladamente.
As ferramentas de visualização são importantes para observar ocomportamento que a aplicação obteve durante a execução. Possibilit am que sejamidentificados os gargalos durante a execução, associando-os aos pontos no código fonte.
Como resultado final deste estudo, observa-se que as idéias apresentadasnesse trabalho podem complementarem-se no anseio de criar um software DSM quealcance os resultados desejáveis, ou seja, um modelo de programação simples e queobtenha bons desempenho. Um sistema que possa através de análise estática fornecerinformações valiosas para o ambiente de execução. Um ambiente de execução queadapte-se ao comportamento da aplicação e as mudanças dinâmicas na arquitetura. Paraisso util izar um algoritmo eficiente de escalonamento de threads que almeje alocalidade dos dados. Aliado a isso técnicas de tolerância a latência para os pontos ondeos algoritmos anteriores não consigam eliminar as latências. Para finalizar umaferramenta que possibilit e a visualização da execução.
67
Como trabalhos futuros poderiam ser destacados a instalação e avaliaçãodas técnicas estudas no Instituto de Informática. Além disso, é possível destacar apossibili dade de estudar propostas que procurem integrar as técnicas que foramapresentadas isoladamente, com o objetivo de criar um sistema DSM robusto, compostopor um processo de compilação, um ambiente de execução e uma ferramenta devisualização.
68
Bibliografia
[AMZ 96] AMZA, Cristiana et al. TreadMarks: Shared Memory Computing onNetwork of Workstations. IEEE Computer, New York, v. 29, n. 2, p.18-28, Feb. 1996.
[AMZ 97] AMZA, Cristiana et al. Tradeoffs Between False Sharing and Aggregationin Software Distributed Shared Memory. In: ACM SIGPLANSYMPOSIUM ON PRINCIPLES AND PRACTICE OF PARALLELPROGRAMMING, PPOPP 97, 6. Proceedings…, p. 90-99, June1997.
[ARA 99] ARAUJO, Edvar B. Um Estudo sobre Sistemas de Memór iaCompartilhada Distr ibuída. Porto Alegre, PPGC-UFRGS, Ago.1999, 59p. (Trabalho Individual – TI 868).
[BRO 98] BRORSSON, Mats & KRAL, Martin. Visualisation for PerformanceTuning of DVSM Applications. In: HAWAII INTERNATIONALCONFERENCE ON SYSTEM SCIENCES, HICSS, 31.Proceedings…, v. 7, p. 532-541, Jan. 1998.
[DUB 98] DUBROVSKI, Alex et al. Load Balancing in Distributed Shared MemorySystems. International Journal of Applied Software Technology, v.3, p. 167-202, Mar. 1998.
[DWA 96] DWARKADA S, SANDHYA et al. An Integrated Compile-Time / Run-Time Software Distributed Shared Memory System. In:SYMPOSIUM ON ARCHITECTURAL SUPPORT FORPROGRAMMING LANGUAGES AND OPERATING SYSTEMS,1996, 7. Proceedings..., Oct. 1996.
[DWA 99] DWARKADA S, SANDHYA et al. Combining Compile-Time and Run-Time Support for Eff icient Software Distributed Shared Memory.Proceedings of the IEEE, Special Issue on Distr ibuted SharedMemory, New York, v. 87, n. 3, p. 476-486, Mar. 1999.
[FRI 97] FRIEDMAN, Roy et al. MILLIPEDE: Easy Parallel Programming inAvailable Distributed Environments. Software - Practice andExper ience, v. 27, n. 8, p. 925-965. Aug. 1997.
[HAL 95] HALL, M. et al. Detecting Coarse-Grain Parallelism Using anInterprocedural Parallelizing Compiler. In: SUPERCOMPUTING,San Diego. Proceedings…, Dec. 1995.
[HAN 97] HAN, Hwansoo et al. Reducing Synchronization Overhead for Compiler-Parallelized Codes on Software DSMs. In: INTERNATIONALWORKSHOP ON LANGUAGES AND COMPILERS FORPARALLEL COMPUTING, LCPC 97, 10. Proceedings…, Aug.1997.
69
[HAN 98] HAN, Hwansoo et al. Eliminating Barrier Synchronization for Compiler-Parallelized Codes on Software DSMs. International Journal ofParallel Programming, v. 26, n. 5, p. 591-612, Oct. 1998.
[HAV 91] HAVLAK, P. & KENNEDY, K. An Implementation of InterproceduralBounded Regular Section Analysis. IEEE Transactions on Paralleland Distr ibuted Systems, v. 2, n.3, p. 350-360, July 1991.
[IOA 98] IOANNIDIS, Sotiris & DWARKADA S, Sandhya. Compiler and Run-Time Support for Adaptive Load Balancing in Software DistributedShared Memory Systems. In: WORKSHOP ON LANGUAGES,COMPILERS, AND RUN-TIME SYSTEMS FOR SCALABLECOMPUTERS, 4., 1998, Proceedings..., 1998.
[ITZ 97] ITZKOVITZ, Ayal et al. Supporting Multiple Parallel ProgrammingParadigms On Top Of The Milli pede Virtual Parallel Machine. In:INTERNATIONAL WORKSHOP ON HIGH LEVELPROGRAMMING MODELS AND SUPPORTIVEENVIRONMENTS, HIPS. Proceedings..., 1997, p. 25-34.
[ITZ 98] ITZKOVITZ, Ayal et al. Thread Migration and its Applications inDistributed Shared Memory Systems. The Journal of Systems andSoftware, v. 47, n. 1, p. 71-87, July 1998.
[ITZ 99] ITZKOVITZ, Ayal & SCHUSTER, Assaf. MultiView and Milli page –Fine-Grain Sharing in Page-Based DSMs. SYMPOSIUM ONOPERATING SYSTEMS DESIGN AND IMPLEMENTATION,OSDI, 3., New Orleans. Proceedings…, p. 215-228, Feb. 1999.
[ITZ 99a] ITZKOVITZ, Ayal et al. Dynamic Adaptation of Sharing Granularity inDSM Systems. INTERNATIONAL CONFERENCE ON PARALLELPROCESSING, ICPP, 28., Aizu, Japan. Proceedings…, Sep. 1999.
[KEL 94] KELEHER, Pete et al. TreadMarks: Distributed Shared Memory onStandard Workstations and Operating Systems. In: WINTER USENIXCONFERENCE, 1994. Proceedings..., 1994, p. 115-131.
[KEL 96] KELEHER, Pete. The Relative Importance of Concurrent Writes andWeak Consistency Models. In: INTERNATIONAL CONFERENCEON DISTRIBUTED COMPUTING SYSTEMS, 16., Hong Kong.Proceedings…, May 1996.
[KEL 97] KELEHER, Pete & TSENG, Chau-Wen. Enhancing Software DSM forCompiler-Parallelized Applications. In: INTERNATIONALPARALLEL PROCESSING SYMPOSIUM, 11. Proceedings…,April 1997.
[KEL 98] KELEHER, Pete et al. Lazy Release Consistency for Software DistributedShared Memory. In: PROTIC, Jelica et al. Distr ibuted SharedMemory: Concepts and Systems. Los Alamitos, Cali fornia: IEEEComputer Society Press, 1998, p. 96-104.
70
[KEN 93] KENNEDY, K et al. Analysis and Transformation in an InteractiveParallel Programming Tool. Concurrency: Practice and Experience.v. 5, n. 7, Oct. 1993.
[LEW 98] LEWIS, B. & BERG, D. J. Multithreading Programming withPthreads. Mountain View, Prentice-Hall , 1998.
[LU 97] LU, H. et al. Compiler and Software Distributed Shared Memory Supportfor Irregular Applications. In: SYMPOSIUM ON THE PRINCIPLESAND PRACTICE OF PARALLEL PROGRAMMING, 6.Proceedings..., p. 48-56, June 1997.
[MEI 96] MEIRA, Wagner Jr. et al. Waiting Time Analysis and PerformanceVisualization in Carnival. In: SIGMETRICS SYMPOSIUM ONPARALLEL AND DISTRIBUTED TOOLS, SPDT. Proceedings…,ACM, Philadelphia, PA, p. 1-10, May 1996.
[MEI 97] MEIRA, Wagner Jr. et al. Understanting the Performance Evaluation ofDSM Applications. In: INTERNATIONAL WORKSHOP ONCOMMUNICATION ANDARCHITECTURAL SUPPORT FORNETWORK-BASED PARALLEL COMPUTING, CANCPC, 1.Proceedings…, p. 198-211, Feb. 1997.
[MOW 94] MOWRY, Todd C. Tolerating Latency Through Software ControlledData Prefetching. PhD Thesis, Stanford University, March 1994.
[MOW 98] MOWRY, Todd C. et al. Comparative Evaluation of Latency ToleranceTechniques for Software Distributed Shared Memory. In:INTERNATIONAL SYMPOSIUM ON HIGH PERFORMANCECOMPUTER ARCHITECTURE, HPCA, 4. Proceedings…, Feb.1998.
[PIN 96] PINTO, Raquel G. et al. Avaliando Técnicas de Prefetching para SoftwareDSMs. In: SIMPÓSIO BRASILEIRO DE ARQUITETURA DECOMPUTADORES E PROCESSAMENTO DE ALTODESEMPENHO, 8., 1996, Recife. Anais... Recife: SBAC-PAD,1996. 245p. p. 57-66.
[PRO 98] PROTIC, Jelica et al. Distr ibuted Shared Memory: Concepts andSystems. Los Alamitos, Cali fornia: IEEE Computer Society Press,1998.
[PRO 99] PROVENZANO, C. Pthreads: an Implementation of Posix 1003.1.c.Disponível por WWW emhttp://www.mit.edu:8001/people/proven/pthreads no dia 28/10/1999.
[SCH 98] SCHUSTER, Assaf & SHALEV, Lea. Using Remote Access Histories forThread Scheduling in Distributed Shared Memory Systems. In:INTERNATIONAL SYSMPOSIUM ON DISTRIBUTEDCOMPUTING, DISC, 12. Proceedings…, Sep. 1998.
71
[SUD 97] SUDO, Y. et al. Distributed Thread Scheduling Methods for ReducingPage-Thrashing. In: IEEE INTERNATIONAL SYMPOSIUM ONHIGH PERFORMANCE DISTRIBUTED COMPUTING, 6.Proceedings…, 1997.
[THI 97] THIKIKAMOL, Kritchalach & KELEHER, Pete. Multi -Threading andRemote Latency in Softwares DSMs. In: INTERNATIONALCONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS,ICDCS, 17. Proceedings…, May 1997.
[THI 98] THIKIKAMOL, Kritchalach & KELEHER, Pete. Per-Node Multi -Threading and Remote Latency. IEEE Transactions on Computers,v. 47, n. 4, p. 414-426, April 1998.
[THI 99] THIKIKAMOL, Kritchalach & KELEHER, Pete. Thread Migration andCommunication Minimization in DSM Systems. Proceedings of theIEEE, Special Issue on Distr ibuted Shared Memory, New York, v.87, n. 3, p. 487-497, Mar. 1999.
[THI 99a] THIKIKAMOL, Kritchalach & KELEHER, Pete. Active CorrelationTracking. In: INTERNATIONAL CONFERENCE ONDISTRIBUTED COMPUTING SYSTEMS, ICDCS, 19.Proceedings…, May 1999.