Redução de OS Jitter em Aplicações de Computação de Alto Desempenho

Transcrição

1 Redução de OS Jitter em Aplicações de Computação de Alto Desempenho Autor: Elder V. P. Sobrinho Orientador: Rivalino Matias Jr. Programa de Pós-Graduação em Ciência da Computação Universidade Federal de Uberlândia Uberlândia, MG Brasil Nível: Mestrado Ano de ingresso no programa: 2010 Época esperada de conclusão: Março/2012 Etapa concluída: Levantamento bibliográfico (parcial) Resumo. Aplicações de HPC são tipicamente projetadas para executar em um paradigma de processamento paralelo, onde as instruções são executadas de forma concorrente entre os diversos nós de processamento e distribuídas em diversas fases computacionais. Recentemente o OS Jitter tem sido considerado um dos principais fatores que podem provocar atrasos no tempo de processamento em ambientes de cluster HPC. Estudos mostram que os efeitos do OS Jitter agravam à medida que os clusters aumentam o número de nós. Portanto, considera-se importante o estudo e o desenvolvimento de formas de reduzir os efeitos do OS Jitter, especialmente para ambientes de HPC. Esse trabalho propõe mudanças arquiteturais no núcleo do sistema operacional como alternativa para reduzir o OS Jitter em aplicações de HPC. Palavras-Chave: OS Jitter, Cluster, HPC, Sistema Operacional

2 1. Introdução e Motivação A evolução científica e tecnológica nas diversas áreas da sociedade tem exigido, cada vez mais, poder computacional para a execução de modelos complexos usados em pesquisas científicas e atividades industriais, os quais na sua maioria requerem elevado tempo de computação [Buyya 1999]. Esse cenário tem impulsionado uma crescente demanda por recursos computacionais de alto desempenho (HPC - High Performance Computing). Mesmo com o grande aumento no poder computacional dos computadores convencionais, que segundo Gordon Moore [Moore 2000] dobra a cada dezoito meses, muitas tarefas ainda continuam exigindo tempo considerável de computação. Nesse caso, o conceito de processamento paralelo é fundamental, pois visa dividir uma tarefa em um subconjunto de tarefas menores para que possam ser processadas ao mesmo tempo por diferentes processadores, estando eles fortemente ou fracamente acoplados [Garg and De 2006]. Os aglomerados de processadores, também chamados de clusters [Garg and De 2006], têm sido usados cada vez mais para o processamento paralelo de alto-desempenho, como alternativa ou complemento dos supercomputadores. Em uma arquitetura típica de um cluster HPC, cada estação de trabalho (nó) executa seu sistema operacional para gerenciar e supervisionar os recursos de hardware e software do nó. Em um grande cluster é comum a existência de centenas ou milhares de nós. O sistema operacional de cada nó possui, além das aplicações de HPC, várias tarefas internas que devem ser executadas com certa regularidade, tais como rotinas para sincronização do buffer-cache com o disco, tratamento de interrupções, dentre outras, Juntamente com essas tarefas internas executam as aplicações do usuário. Observa-se que durante o período de execução da aplicação do usuário essa sofre, por diversas vezes, a interferência das tarefas internas do sistema operacional - mencionadas anteriormente. Essas interferências têm sido investigadas e atualmente são denominadas na literatura de OS Jitter [De et al. 2007], [Mann and Mittaly 2009] e [IBM 2010] ou OS Noise [De et al. 2007], [Gioiosa et al. 2004], [Agarwal et al. 2005], [Tsafrir et al. 2005] e [Garg and De 2006]. Aplicações de HPC são tipicamente projetadas para executar em um paradigma de processamento paralelo, em que as instruções são executadas de forma concorrente entre os diversos nós de processamento e distribuídas em diversas fases computacionais [Garg and De 2006]. Após o processamento de cada fase computacional, os nós alocados são sincronizados e, dessa forma, as fases computacionais subseqüentes são executadas apenas quando a fase computacional atual é completamente processada por todos os nós [Gioiosa at al. 2004], [Agarwal et al. 2005] e [Tsafrir et al. 2005]. Nesse caso, o tempo de processamento de cada fase é um fator crítico, pois qualquer atraso que ocorra em um nó será propagado ao longo de todos os nós alocados para uma aplicação, acarretando assim um tempo maior para processar cada fase e, por conseqüência, mais tempo será necessário para completar a tarefa. Recentemente o OS Jitter tem sido considerado um dos principais fatores que podem provocar atrasos no tempo de processamento em ambientes de cluster HPC, além de fatores já conhecidos como latência da rede de interconexão, latência dos dispositivos de I/O, configuração dos nós não homogêneo, entre outros. Estudos [Jones

3 et al. 2003], [Gioiosa et al. 2004], [Agarwal et al. 2005], [Tsafrir et al. 2005] e [Garg and De 2006] mostram que os efeitos do OS Jitter agravam à medida que os clusters aumentam o número de nós. Portanto, considera-se importante o estudo e o desenvolvimento de formas de reduzir os efeitos do OS Jitter, especialmente para ambientes de HPC. Esse trabalho propõe mudanças arquiteturais no núcleo do sistema operacional como alternativa para reduzir o OS Jitter em aplicações de HPC. 2. Trabalhos Relacionados [Mogul and Borg 1991] desenvolveram experimentos para medir o custo da troca de contexto na performance do cache de processador. Foi testada uma variedade de programas executando de forma concorrente em um sistema operacional Unix. Dependendo dos parâmetros do sistema de cache, foi encontrada uma média de custo de até dezenas ou centenas de microssegundos para uma troca de contexto. O alto custo da troca de contexto é um dos fatores que faz a performance do sistema operacional não se manter no mesmo ritmo que as melhorias de hardware. Além do custo de salvar e restaurar registradores, outro fator até então considerado era a interferência no cache. Para entender o tamanho dessa influência, [Fromm and Treuhaft 1996] quantificaram os efeitos dessa interferência como consequência da troca de contexto em um ambiente multi-programado. Utilizando um simulador para coleta de dados, determinou-se que a interferência da troca de contexto não chega a 1% da taxa total de cache miss, ou seja, é muito pequena. Mesmo se todos os cache misses da troca de contexto fossem eliminados e cada cache miss custasse muitas centenas de ciclos, os programas só poderiam rodar aproximadamente 30% mais rápido. Assim, a completa eliminação de todas as interferências no cache da troca de contexto tem um impacto mínimo no tempo total de execução. [ Jones et al. 2003] investigam o impacto negativo do sistema operacional na escalabilidade e performance de aplicações paralelas em grandes clusters. Foram identificados dois tipos de interferências, as de longa e curta duração. Essas são respectivamente causadas por processos executando em segundo plano (ex. daemons) e rotinas internas ao sistema operacional (ex. timers). Os resultados sugerem que as interferências de daemons podem ser minimizadas ao executar aplicações em nós contendo um ou mais processadores livres que seriam dedicados para tratar os eventos do sistema operacional. Por exemplo, manter um processador livre para aplicações próprias do sistema como em um nó contendo 16 processadores executando 15 processos, um em cada processador. [Gioiosa et al. 2004] assim como [Jones at al. 2003], estudam o impacto do sistema operacional em aplicações paralelas. Através da implementação de um benchmark foi possível identificar as fontes de ruído do sistema e quantificar o impacto total sobre a aplicação. A principal contribuição do estudo é fornecer e demonstrar uma metodologia eficaz para identificar e quantificar o ruído em grandes clusters. Os resultados indicam que as principais fontes de ruído são devido à interrupção de timer. [Agarwal et al.2005] apresentam uma modelagem teórica do impacto do OS Jitter na performance de uma determinada classe de aplicações paralelas usando diferentes distribuições de probabilidade. Segundo os autores, essa foi a primeira

4 tentativa de explicar o impacto do jitter com modelo matemático. Os resultados mostram que na presença de jitter com uma distribuição exponencial o sistema tem uma boa escalabilidade, entretanto, quando esse segue uma distribuição de Bernoulli ou Pareto a performance diminui drasticamente. [Tsafrir et al. 2005] apresentam uma abordagem para quantificar o efeito do OS jitter utilizando modelagem probabilística. Eles implementaram um micro-benchmark e equiparam o kernel do Linux para gravar as interrupções do sistema operacional. Foi determinado que a principal fonte de OS jitter são os timer ticks e que a redução deles é uma possível solução para o problema. Para eliminar esse jitter foi sugerida a substituição do timer tick por um mecanismo alternativo denominado smart ticks que promove a temporização precisa agregando eventos próximos. Entretanto, não resolve o problema por completo, pois apenas reduz a incidência. [Garg and De 2006] buscam validar seu modelo, baseado em experiências anteriores, com dados coletados de clusters de grande escala. Para a execução do experimento foi necessária a criação de um benchmark paralelo para medir a distribuição do Jitter no cluster. A partir dos dados coletados, foram feitas previsões de desempenho baseando-se no modelo analítico desenvolvido anteriormente por [Agarwal et al. 2005]. Por esse modelo, foi descoberto que as medições de distribuições do Jitter ajudam na identificação de comportamentos anômalos em nós dos clusters. [Li et al. 2007] mostram uma quantificação do custo indireto da troca de contexto através de experimentos usando uma carga de trabalho artificial. Especificamente foi medido o impacto do tamanho de dados e da forma de acesso na troca de contexto. Também foi abordado o potencial impacto dos tratadores de interrupção do sistema operacional na precisão das medições. Os resultados indicam que, em geral, o custo indireto da troca de contexto está entre alguns microssegundos e mais de mil microssegundos, conforme a carga de trabalho. [De et al. 2007] apresentam o projeto e implementação de uma ferramenta para ajudar a identificar as fontes de OS Jitter em sistemas operacionais Linux. Essa pode ser usada para medir quantitativamente a contribuição do OS Jitter por vários daemons e interrupções do sistema. Os experimentos mostram que a principal fonte de OS Jitter é proveniente da interrupção de timer (63%). Os experimentos também ajudam a identificar daemons que podem ser facilmente eliminados como é o caso do hidd (bluetooth hardware interface device daemon) que contribui em 9% do OS Jitter. 4. Contribuição do Trabalho Os trabalhos apresentados na seção anterior discutem os diversos tipos de interferências (OS Jitter) do sistema operacional na execução de aplicações no espaço do usuário, em especial aplicações de HPC. Dentre essas interferências, destacam-se a execução de processos administrativos (daemons) e rotinas periódicas do núcleo (kernel) tais como a interrupção de clock (timer). Esse trabalho pretende contribuir para a redução do OS Jitter atacando principalmente esses dois problemas no sistema operacional Linux. A escolha do Linux deve-se principalmente pela disponibilidade do seu código fonte e por atualmente ser o sistema operacional mais usado em clusters de HPC, sendo usado em 82% dos computadores/clusters listados na internet [Top ].

5 A proposta para reduzir a influência dos processos administrativos nas aplicações HPC é a utilização de uma abordagem de escalonamento assimétrico, visando um melhor uso do tempo de processador e, conseqüentemente, do seu cache. Essa hipótese será testada frente a diferentes tipos de aplicações de HPC, em especial, aplicações do tipo CPU-bound e I-O bound. Já com relação à interferência causada pelo timer, uma proposta de processadores tickless. Atualmente, o núcleo do Linux suporta uma abordagem similar para a redução do consumo de energia. Esse trabalho aproveitará a implementação atual de tickless do núcleo do Linux para viabilizar a execução de processos CPU-bound sem interrupções de timer. 5. Metodologia de Pesquisa Esse trabalho seguirá um enfoque teórico-experimental. O estudo teórico envolverá o entendimento dos aspectos fundamentais dos dois principais componentes envolvidos no estudo, a saber: escalonamento SMP e interrupção de clock. A relação desses componentes com os demais subsistemas do núcleo é de especial importância. Nessa etapa, uma revisão detalhada da literatura, bem como a revisão do código atual do núcleo do Linux serão as principais fontes de informações usadas. Com base nesse estudo, as propostas de implementação serão realizadas e avaliadas. Na etapa experimental, serão realizados experimentos controlados para avaliar as propostas em questão. Experimentos serão elaborados para avaliar os efeitos do escalonamento assimétrico no tempo de execução de aplicações de HPC. Inicialmente, pretende-se utilizar como estudos de caso aplicações de CFD (Computational Fluid Dynamics) do Laboratório de Mecânica dos Fluidos (MFLab) do Departamento de Engenharia Mecânica da UFU. A técnica de DOE (Design of Experiments) [Montgomery 2005] será utilizada para o planejamento dos experimentos e análise estatística dos seus resultados. 6. Cronograma do trabalho 1. Levantamento Bibliográfico 2. Elaboração e Defesa do Plano de Trabalho 3. Escrita da dissertação. 4. Análise Exploratória do Código do Escalonador SMP do Linux 5. Análise Exploratória da Infra-estrutura atual de Tickless 6. Elaboração e Execução dos Experimentos 7. Análise dos Dados 8. Eventuais testes adicionais /correções/etc 9. Preparar apresentação da defesa de dissertação 10. Defesa

6 Tabela 1: Cronograma de execução das atividades propostas 7. Referências Ousterhout, J. K. and K, J. (1990). Why aren t operating systems getting faster as fast as hardware? Mogul, J. C. and Borg, A. (1991). The effect of context switches on cache performance. SIGPLAN Not., 26: Anderson, E. and Pasquale, J. (1995). The performance of the container shipping I/O system. Fromm, R. and Treuhaft, N. (1996). Revisiting the cache interference costs of context switching. Pai, V. S., Druschel, P., and Zwaenepoel,W. (1999). IO-lite: A unified I/O buffering and caching system. In ACM Transactions on Computer Systems, pages Buyya, R. (1999). In High Performance Cluster Computing: Architectures and Systems, Volume 1. Prentice Hall PTR. Moore, G. E. (2000). Readings in computer architecture. chapter Cramming more components onto integrated circuits, pages Morgan Kaufmann Publishers Inc., San Francisco, CA, USA. Burnside, M. and Keromytis, A. D. (2003). High-speed I/O: The operating system as a signalling mechanism. Jones, T. R., Brenner, L. B., and Fier, J. M. (2003). Impacts of operating systems on the scalibility of parallel applications. Gioiosa, R., Petrini, F., Davis, K., and Lebaillif-Delamare, F. (2004). Analysis of system overhead on parallel computers. In Signal Processing and Information Technology, Proceedings of the Fourth IEEE International Symposium on, pages Agarwal, S., Garg, R., and Vishnoi, N. K. (2005). The impact of noise on the scaling of collectives: a theoretical approach. In HiPC, pages Tsafrir, D., Etsion, Y., Feitelson, D. G., and Kirkpatrick, S. (2005). System noise, OS clock ticks, and fine-grained parallel applications. Montgomery, D. C. (2005). Design and Analysis of Experiments. John Wiley, 3 edition. Garg, R. and De, P. (2006). The impact of noise on the scaling of collectives: an empirical evaluation. In High Performance Computing (HiPC).

7 Li, C., Ding, C., and Shen, K. (2007). Quantifying the cost of context switch. In Proceedings of the 2007 workshop on Experimental computer science, ExpCS 07, New York, NY, USA. ACM. De, P., Kothari, R., and Mann, V. (2007). Identifying sources of operating system jitter through fine-grained kernel instrumentation. In Proceedings of the 2007 IEEE International Conference on Cluster Computing, CLUSTER 07, pages , Washington, DC, USA. IEEE Computer Society. Mann, P. D. V. and Mittaly, U. (2009). Handling os jitter on multicore multithreaded systems. In Proceedings of the 2009 IEEE International Symposium on Parallel & Distributed Processing, pages 1 12, Washington, DC, USA. IEEE Computer Society. Top 500 (2010). Top 500 supercomputer sites. Acessado em 20 de Novembro de IBM (2010). Identifying Jitter Sources. _projects.nsf/pages/osjitter.identifying.html. Acessado em 21 de Novembro de 2010.