LTMS - Lups Transactional Memory Scheduler: um escalonador NUMA-Aware para STM
Memória transacional em Software (STM) é uma alternativa à sincronização utilizando locks e monitores. A STM permite ao programador escrever códigos paralelos de forma mais simples, pois é possível substituir o uso de bloqueios por blocos atômicos. Porém, com o aumento do paralelismo existe um aumen...
| Autor: | |
|---|---|
| Tipo de recurso: | tesis de maestría |
| Estado: | Versión publicada |
| Fecha de publicación: | 2021 |
| País: | Brasil |
| Institución: | Universidade Federal de Pelotas (UFPEL) |
| Repositorio: | Repositório Institucional da UFPel - Guaiaca |
| Idioma: | portugués |
| OAI Identifier: | oai:guaiaca.ufpel.edu.br:prefix/8016 |
| Acceso en línea: | http://guaiaca.ufpel.edu.br/handle/prefix/8016 |
| Access Level: | acceso abierto |
| Palabra clave: | CNPQ::CIENCIAS EXATAS E DA TERRA::CIENCIA DA COMPUTACAO Computação Memórias Transacionais - TM Non-Uniform Memory Access - NUMA Escalonador Transactional Memory - TM Scheduler |
| Sumario: | Memória transacional em Software (STM) é uma alternativa à sincronização utilizando locks e monitores. A STM permite ao programador escrever códigos paralelos de forma mais simples, pois é possível substituir o uso de bloqueios por blocos atômicos. Porém, com o aumento do paralelismo existe um aumento na contenção que em STM se reflete em um maior número de conflitos. Buscando otimizar o desempenho de STM, muitos estudos focam na redução do número de conflitos por meio de escalonadores. Contudo, nas arquiteturas atuais também é importante considerar onde a memória do programa está alocada e como ela é acessada. Esta dissertação propõe um escalonador NUMA-Aware para STM, intitulado Lups Transactional Memory Scheduler (LTMS), o qual em tempo de execução, coleta dados sobre a aplicação e arquitetura utilizada para otimizar a execução de STM em arquiteturas NUMA. Para isto a estratégia de escalonamento é dividido em três etapas. A primeira fornece um mecanismo de inicialização, com criação de filas que reflitam a arquitetura e estratégias de distribuição de threads, para analisar o impacto que a distribuição de threads possui sobre a aplicação. A segunda etapa apresenta um mecanismo para coletar dados em tempo de execução, nesta etapa são coletados dados sobre as threads e suas transações, os acessos à memória e a arquitetura utilizada. A terceira etapa traz um sistema para migração de threads em tempo de execução, o qual entra em ação após a ocorrência de um conflito, esta etapa busca agrupar threads conflitantes minimizando conflitos futuros e reduzindo o custo de acesso à memória. Para a tomada de decisão desta etapa, foram desenvolvidas duas heurísticas para entender o comportamento da STM em relação ao custo de latência e intensidade de conflitos. Para realização de testes o LTMS foi implementado junto a biblioteca TinySTM e foi utilizado com conjunto de benchmarks STAMP. Os experimentos foram executados utilizando as diferentes estratégias de distribuição e migração de threads desenvolvidos e comparados com a biblioteca TinySTM 1.0.5. Os experimentos apresentaram para maioria dos benchmarks menor taxa de abort e melhor tempo de execução. |
|---|