Upload
dinhduong
View
218
Download
0
Embed Size (px)
Citation preview
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS Programa de Pós-Graduação em Engenharia Elétrica
João Batista Torres Corrêa
PREDIÇÃO DE CONFIGURAÇÃO EM ESCALONADORES RECONFIGU RÁVEIS DE TAREFAS PARALELAS FUNDAMENTADA NA REGULARIDADE T EMPORAL
DA CARGA DE TRABALHO
Belo Horizonte 2011
João Batista Torres Corrêa
PREDIÇÃO DE CONFIGURAÇÃO EM ESCALONADORES RECONFIGU RÁVEIS DE TAREFAS PARALELAS FUNDAMENTADA NA REGULARIDADE T EMPORAL
DA CARGA DE TRABALHO
Dissertação apresentada ao Programa de Pós-Graduação em Engenharia Elétrica da Pontifícia Universidade Católica de Minas Gerais no 1º semestre de 2011, como requisito parcial para obtenção do título de Mestre em Engenharia Elétrica.
Orientador: Prof. Dr. Carlos Augusto Paiva da Silva Martins
Belo Horizonte 2011
FICHA CATALOGRÁFICA Elaborada pela Biblioteca da Pontifícia Universidade Católica de Minas Gerais
Corrêa, João Batista Torres C824p Predição de configuração em escalonadores reconfiguráveis de tarefas paralelas
fundamentada na regularidade temporal da carga de trabalho / João Batista Torres Corrêa. Belo Horizonte, 2011.
83f. : Il.
Orientador: Carlos Augusto Paiva da Silva Martins Dissertação (Mestrado) – Pontifícia Universidade Católica de Minas Gerais. Programa de Pós-Graduação em Engenharia Elétrica. 1. Sistemas de controle ajustável. 2. Processamento paralelo (Computadores).
I. Martins, Carlos Augusto Paiva da Silva. II. Pontifícia Universidade Católica de Minas Gerais. Programa de Pós-Graduação em Engenharia Elétrica. III. Título.
CDU: 681.3-11
João Batista Torres Corrêa
PREDIÇÃO DE CONFIGURAÇÃO EM ESCALONADORES RECONFIGU RÁVEIS DE TAREFAS PARALELAS FUNDAMENTADA NA REGULARIDADE T EMPORAL
DA CARGA DE TRABALHO
Dissertação apresentada ao Programa de Pós-Graduação em Engenharia Elétrica da Pontifícia Universidade Católica de Minas Gerais, como requisito parcial para obtenção do título de Mestre em Engenharia Elétrica.
__________________________________________________________ Prof. Dr. Carlos Augusto Paiva da Silva Martins (Orientador) – PUC Minas
__________________________________________________________ Prof. Dr. Adriano César Machado Pereira – CEFET/MG
__________________________________________________________ Prof. Dr. Carlos Alberto Marques Pietrobon – PUC Minas
Belo Horizonte, 26 de abril de 2011.
AGRADECIMENTOS
Agradeço a todos que, de alguma forma, ajudaram na realização desta pesquisa. Em
especial ao meu orientador Carlos Augusto e ao meu co-orientador Luis Fabrício pelo apoio,
paciência, ajuda e orientação durante o período de realização desta pesquisa e principalmente
pela amizade de ambos e pelas experiências profissionais e pessoais passadas. Agradeço aos
meus pais, meus irmãos e minha família pela criação que tive e pelo apoio, amor e amizade
que sempre recebi. A minha namorada Raquel pelo amor, paciência e torcida. Agradeço a
meus amigos pela amizade e força. E a todos por sempre acreditarem em mim e por
entenderem os momentos em que não estive presente, os quais investi na realização desta
pesquisa.
Aos amigos de mestrado e pesquisa, agradeço pela ajuda nos trabalhos e pelo
companheirismo em diversos momentos. De forma especial ao Lesandro Santos pela ajuda
dada na realização desta pesquisa.
Um agradecimento especial para a Pontifícia Universidade Católica de Minas Gerais e
ao Programa de Pós-Graduação em Engenharia Elétrica pela formação recebida.
RESUMO
O objetivo principal desta pesquisa é propor e desenvolver um controle de configuração para
escalonadores reconfiguráveis de tarefas paralelas utilizando predição das melhores
configurações e que seja fundamentado no agrupamento e na modelagem estatística das
cargas de trabalho executadas no passado. Para isso, utilizamos o algoritmo Reconfigurable
Gang Scheduling Algorithm (RGSA) e introduzimos no mesmo uma nova camada de controle
de configuração (CCC). Com isso, passamos a utilizar como parâmetros de entrada para a
tomada de decisão do escalonamento do RGSA, a regularidade temporal de acordo com as
características das cargas de trabalho que foram preditas em períodos anteriores. Esta solução
visa propor uma versão do RGSA que seja mais próxima da realidade e que seja possível e
viável de se implementar em sistemas reais. A nossa meta principal é, então, uma nova
camada CCC do RGSA utilizando predição das configurações fundamentada na análise,
agrupamento e modelagem estatística das cargas de trabalho executadas no passado. Desta
forma, implementamos nesta pesquisa uma nova CCC baseada em regularidade temporal e
que utiliza rastros de cargas de trabalho reais executadas em períodos de tempo diferentes
para identificar as características dessas cargas. De posse dessas informações das cargas
referentes ao passado, a CCC pode tomar melhores decisões. Além disto, propomos um novo
mecanismo do RGSA de alteração de configurações da camada CCC. A principal
contribuição deste trabalho é a apresentação de um novo controle de configuração para
escalonadores reconfiguráveis de tarefas paralelas que utiliza a predição baseada na
regularidade temporal das cargas de trabalho executadas no passado. Este controle foi
implementado na Camada de Controle de Configuração (CCC) do RGSA, que chamamos de
CCC Proposta. Este novo controle é uma evolução da CCC do RGSA Original, a qual realiza
a reconfiguração do escalonador baseado na anotação das cargas que são enviadas juntamente
com a própria carga no momento de submissão. O RGSA com a CCC Proposta está mais
próximo da realidade com a inclusão do novo controle de configuração proposto nesta
pesquisa. O RGSA Proposto não necessita da anotação das cargas para escolher a
configuração que o escalonador irá utilizar, pois utilizando este novo controle de
configuração, usa a predição fundamentada em agrupamento e modelagem estatística da carga
de trabalho para predizer as configurações. Este controle se baseia nas execuções de cargas de
trabalho passadas para as tomadas de decisão utilizando a “Técnica de Caracterização de
Cargas de Trabalho de Supercomputadores”.
Palavras-chave: Computação reconfigurável, Escalonador de tarefas paralelas, Escalonador
reconfigurável de tarefas.
ABSTRACT
The main objective of this research is to propose and develop a configuration control for
reconfigurable parallel task schedulers using prediction of the best settings and based on the
clustering and statistical modeling of workloads run in the past. We used the algorithm
Reconfigurable Gang Scheduling Algorithm (RGSA) and introduced a new layer in the same
configuration control layer (CCC). Thus, we now use as input parameters for decision making
of RGSA scheduling, the temporal regularity according to the characteristics of the workloads
that were predicted in previous periods. This solution aims to propose a version of RGSA that
is closer to reality and that make possible and feasible to implement in real systems. Our main
goal is a new CCC layer of RGSA with prediction using the settings based on the analysis,
clustering and statistical modeling of workloads run in the past. So in this research we
implemented a new CCC based on temporal regularity and using real workloads traces run in
different time periods to identify the characteristics of these loads. With this information of
workloads relating to the past, the CCC can make better decisions. In addition, we propose a
new mechanism for RGSA of changing the layer settings of CCC. The main contribution of
this work is to present a new configuration control for reconfigurable parallel task schedulers
using the prediction based on temporal regularity of workloads run in the past. This control
was implemented at Configuration Control Layer (CCC) of RGSA and we call it as Proposed
CCC. This new control is an evolution of CCC from Original RGSA, which performs the
reconfiguration scheduler based on the annotation of the loads that are sent along with the
load itself at the time of submission. The RGSA with the Proposed CCC is closer to the
reality with the addition of these new control configuration proposed on this research. The
Proposed RGSA doesn’t need any load annotation to choose the configuration that the
scheduler will set, because when using this new configuration control it will use the
configuration based on clustering and statistical modeling of the workload to predict settings.
This control is based on the execution of workloads in the past to make decision using the
"Characterization Technique of Supercomputer Workloads."
Keywords: Reconfigurable Computing, Parallel Task Scheduler, Reconfigurable Task
Scheduler.
LISTA DE FIGURAS
FIGURA 1 - Modelo de Algoritmo Reconfigurável...................................................... 29
FIGURA 2 - Uma das configurações do RGSA............................................................ 30
FIGURA 3 - Representação simplificada do RGSA Original....................................... 34
FIGURA 4 - Proposta de solução para a CCC do RGSA - RGSA com CCC
Proposta..................................................................................................... 36
FIGURA 5 - Exemplo de Regularidade Temporal de cargas de trabalho...................... 36
FIGURA 6 - Parte de arquivo sintético .WKL com dados de um intervalo do dia 0 de
uma semana e das horas 0 a 7................................................................... 38
FIGURA 7 - Fluxo de geração da CCC Proposta para uma carga, composto pelas
Fases de Predição e de Execução.............................................................. 41
FIGURA 8 - Parte do arquivo .SWF referente à carga HPC2N..................................... 46
FIGURA 9 - Parte do arquivo .LOG referente à carga HPC2N mostrada na
Figura 8..................................................................................................... 46
FIGURA 10 - Fluxo de geração da CCC Proposta na Fase de Predição (modo
probabilístico utilizando agrupamento e modelagem estatística) para
carga de Janeiro/2000............................................................................... 47
FIGURA 11 - Fase de Execução (modo determinístico) para carga de
Fevereiro/2000.......................................................................................... 48
FIGURA 12 - Estrutura de testes de verificação do RGSA com a CCC Proposta........ 49
FIGURA 13 - Comparação de esforço para calcular RGSA Ideal e Aproximado......... 67
LISTA DE GRÁFICOS
GRÁFICO 1 - Preditor gerado para a Carga HPC2N.................................................... 56
GRÁFICO 2 - Preditor gerado para a Carga LANLCM5.............................................. 57
GRÁFICO 3 - Preditor gerado para a Carga SDSC....................................................... 59
GRÁFICO 4 - Tempo de execução para a carga HPC2N.............................................. 61
GRÁFICO 5 - Tempo de execução para a carga LANLCM5........................................ 63
GRÁFICO 6 - Tempo de execução para a carga SDSC................................................. 65
GRÁFICO 7 - Comparativo dos tempos de execução para a carga HPC2N
(melhor tempo, pior tempo, RGSA com a CCC Proposta e RGSA
Aproximado)........................................................................................... 68
GRÁFICO 8 - Comparativo dos tempos de execução para a carga LANLCM5
(melhor tempo, pior tempo, RGSA com a CCC Proposta e RGSA
Aproximado)........................................................................................... 69
GRÁFICO 9 - Comparativo dos tempos de execução para a carga SDSC
(melhor tempo, pior tempo, RGSA com a CCC Proposta e RGSA
Aproximado)........................................................................................... 70
LISTA DE QUADROS
QUADRO 1 - Exemplo de temporalidade com período de uma semana e intervalo
em horas da semana.................................................................................. 38
QUADRO 2 - Configurações do RGSA Original.......................................................... 40
QUADRO 3 - Exemplo de tabela de configurações da nova CCC Proposta para o
RGSA com intervalos em horas da semana e período de 1 semana......... 42
LISTA DE TABELAS
TABELA 1 - Médias por hora referentes às características das cargas utilizadas na
Fase de Predição....................................................................................... 50
TABELA 2 - Configurações utilizadas nos resultados da carga HPC2N - Fase de
Predição..................................................................................................... 57
TABELA 3 - Configurações utilizadas nos resultados da carga LANLCM5 - Fase de
Predição..................................................................................................... 58
TABELA 4 - Configurações utilizadas nos resultados da carga SDSC - Fase de
Predição..................................................................................................... 59
TABELA 5 - Tempo de execução HPC2N - RGSA com a CCC Proposta em relação
às 12 configurações fixas.......................................................................... 62
TABELA 6 - Tempo de execução LANLCM5 - RGSA com a CCC Proposta em
relação às 12 configurações fixas............................................................. 64
TABELA 7 - Tempo de execução SDSC - RGSA com a CCC Proposta em relação
às 12 configurações fixas.......................................................................... 66
TABELA 8 - Dados comparativos das cargas de trabalho contendo as médias das
características por hora utilizadas na Predição, obtidas com modelagem
estatística, e Execução.............................................................................. 72
TABELA 9 - Comparação entre as configurações fixas e o RGSA com a CCC
Proposta para as cargas............................................................................. 73
TABELA 10 - Tempo médio de execução das cargas de trabalho com as 12
configurações fixas comparados ao RGSA com a CCC Proposta
utilizadas na execução............................................................................... 75
LISTA DE SIGLAS
CB - Camada Básica (do algoritmo RGSA)
CCC - Camada de Controle de Configuração (do algoritmo RGSA)
COTS - Commodity-Off-The-Shelf
CPI - Ciclos por Instrução
CR - Camada Reconfigurável (do algoritmo RGSA)
DJM - Distributed Job Manager
EP - Elemento de Processamento
FCFS - First Come First Served
GSA - Gang Scheduling Algorithm
GUR - Grid Universal Remote
HPC - High Performance Computing
HPC2N - High Performance Computing Center North
.WKL - extensão de arquivos de workload
LANL - The Los Alamos National Lab
LSDC - Laboratório de Sistemas Digitais e Computacionais
MIMD - Multiple Instruction Multiple Data
MISD - Multiple Instruction Single Data
PPGEE - Programa de Pós-Graduação em Engenharia Elétrica
RGSA - Reconfigurable Gang Scheculing Algorithm
SCI - Scalable Coherent Interface
SDSC - The San Diego Supercomputer Center
SIMD - Single Instruction Multiple Data
SISD - Single Instruction Single Data
SJF - Short Job First
SMP - Symmetric Multi Processor
SO - Sistema Operacional
SSI - Single System Image
SWF - Standard Workload Format
.SWF - extensão de arquivos do padrão SWF (Standard Workload Format)
SUMÁRIO
1 INTRODUÇÃO......................................................................................................... 14 1.1 Contexto da Pesquisa............................................................................................. 14 1.2 Problema Motivador.............................................................................................. 17 1.3 Hipótese de Solução............................................................................................... 18 1.4 Objetivos e Metas................................................................................................... 19 1.5 Justificativa............................................................................................................. 20 1.6 Escopo..................................................................................................................... 21 1.7 Organização do restante do texto......................................................................... 22 2 REVISÃO BIBLIOGRÁFICA................................................................................. 23 2.1 Arquiteturas Paralelas........................................................................................... 23 2.2 Escalonamento de Tarefas Paralelas.................................................................... 24 2.3 Escalonamento de Gangues................................................................................... 26 2.4 Reconfigurable Gang Scheduling Algorithm...................................................... 27 2.5 Trabalhos Relacionados........................................................................................ 30 3 PROPOSTA DE SOLUÇÃO.................................................................................... 32 3.1 Contexto da Proposta de Solução......................................................................... 32 3.2 Análise da Camada de Controle de Configuração Original.............................. 33 3.3 Proposta de Solução............................................................................................... 35 3.4 Considerações Finais.............................................................................................. 43 4 RESULTADOS.......................................................................................................... 44 4.1 Ambiente de Experimentação............................................................................... 44 4.1.1 Cargas de Trabalho.............................................................................................. 44 4.1.2 Análise Comparativa das Cargas de Trabalho Utilizadas na Fase de
Predição................................................................................................................ 49 4.1.3 Configuração dos Experimentos......................................................................... 52 4.1.4 Recursos Computacionais.................................................................................... 54 4.2 Fase de Predição..................................................................................................... 55 4.3 Fase de Execução (Operação)............................................................................... 60 4.3.1 Fase de Execução com a Carga HPC2N............................................................ 60 4.3.2 Fase de Execução com a Carga LANLCM5..................................................... 62 4.3.3 Fase de Execução com a Carga SDSC............................................................... 64 4.4 Análise dos Resultados........................................................................................... 66 4.5 Considerações Finais.............................................................................................. 75 5 CONCLUSÃO........................................................................................................... 77 5.1 Discussão dos Resultados....................................................................................... 77 5.2 Principais Contribuições....................................................................................... 78 5.3 Trabalhos Futuros.................................................................................................. 79 REFERÊNCIAS........................................................................................................... 81
14
1 INTRODUÇÃO
Neste capítulo, é descrito inicialmente o contexto da pesquisa. Posteriormente,
apresentamos o problema motivador e a hipótese de solução desta pesquisa. Os próximos
tópicos são os objetivos e metas; a justificativa, contendo a importância e a relevância; e o
escopo da pesquisa. Finalmente, apresentamos a organização do restante do texto desta
dissertação.
1.1 Contexto da Pesquisa
Nos últimos anos, a demanda por computação de alto desempenho, ou High
Performance Computing (HPC) tem aumentado significativamente. Assim como o tempo de
processamento tem sido um fator de importância, o custo e a qualidade dos resultados
produzidos também são importantes. Deste modo, empresas e instituições de ensino vêm
pesquisando e investindo na área de sistemas de computação de alto desempenho para atender
às suas demandas. Esses investimentos têm sido realizados principalmente em sistemas de
computação distribuídos e paralelos (GÓES; MARTINS, 2004b; STERLING; STARK,
2009).
Dois objetos importantes na análise da operação de um sistema de computação
paralelo são a sua arquitetura paralela e a sua carga de trabalho, que é executada pelo sistema
de computação paralelo. Como exemplos de arquiteturas paralelas, podemos citar os
multiprocessadores e os multicomputadores.
Os multiprocessadores são sistemas compostos por vários elementos de processamento
(EP). Quando falamos sobre EP, nos referimos a algum componente ou dispositivo que
possua a característica de processar dados. Nos multiprocessadores, os EPs possuem um
mesmo espaço de endereçamento de memória e compartilham por sua vez uma mesma
memória. Assim, a comunicação é feita por meio de leituras e escritas em variáveis na
memória compartilhada. Como exemplos, temos grande parte dos processadores multi-core; e
Symmetric Multi Processor (SMP), processadores simétricos interligados e que compartilham
um mesmo espaço de endereçamento de memória.
Os multicomputadores são sistemas compostos por nodos interligados entre si por
meio de uma rede de interconexão. Cada nodo possui seu(s) próprio(s) EP(s) e seu próprio
espaço de endereçamento de memória. A comunicação acontece via troca de mensagens
15
utilizando o meio de interligação existente. Como exemplos de multicomputadores, podemos
citar os aglomerados de computadores (comumente conhecidos por clusters); e as grades
computacionais.
Temos então alguns aspectos importantes:
a) a arquitetura paralela do sistema de computação paralelo;
b) o código executável/rotina ou aplicação;
c) os dados de entrada da aplicação;
d) o modo de interação do usuário.
O código executável/rotina é executado(a) sobre a arquitetura paralela a fim de
processar os dados de entrada da aplicação de acordo com o modo de interação do usuário. E
a junção do código executável/rotina, os dados a serem processados e o modo de interação do
usuário chamaremos de carga de trabalho. Para completar o sistema de computação,
precisamos de uma interface e/ou de um sistema operacional (SO) para gerenciar a execução
da carga de trabalho pelo sistema de computação paralelo.
O sistema operacional possui um serviço de escolha para fazer com que a carga de
trabalho seja executada em determinado momento e em determinado EP. Esse serviço é
chamado de escalonamento de tarefas. Assim, o escalonador de tarefas é o módulo ou camada
que faz a escolha de qual EP irá executar cada uma das tarefas da carga de trabalho. As
decisões ou simplesmente as escolhas que o escalonador deve realizar são várias, entre as
quais podemos destacar as relacionadas às políticas de escalonamento. Então, uma boa
política de escalonamento é aquela que utiliza da forma mais eficiente os recursos
computacionais existentes (BUYYA, 1999; HWANG; XU, 1998; EL-REWINI; ALI; LEWIS,
1995; FRACHTENBERG; SCHWIEGELSHOHN, 2007), levando em consideração as
características das cargas de trabalho executadas.
Vale ressaltar a importância do escalonador em satisfazer o tempo, o custo e a
qualidade dos resultados produzidos em um sistema de computação paralelo. Assim, a escolha
de uma política de escalonamento adequada aos recursos computacionais e às cargas de
trabalho submetidas é de extrema importância. A escolha de uma política de escalonamento
que seja a mais apropriada ao problema se dá por meio de análises das características das
cargas de trabalho que serão executadas e dos recursos computacionais existentes.
16
Com relação ao escalonamento, existem dois tipos principais: o escalonamento
estático, que faz a distribuição das tarefas entre os EPs antes do início da execução das
tarefas; e o escalonamento dinâmico, que faz a distribuição das tarefas em tempo de execução.
Em ambos os casos (estático ou dinâmico), os sistemas de computação não
caracterizados como sistemas de tempo real, não podem garantir um desempenho desejado,
ou mesmo ideal. Isso devido à heterogeneidade das cargas de trabalho e ao comportamento
dinâmico dos sistemas de computação (GÓES; MARTINS, 2004b).
Com o intuito de melhorar a qualidade do escalonamento, várias soluções foram
propostas e desenvolvidas. Dentre as soluções, destacamos o algoritmo de escalonamento
paralelo de tarefas denominado Algoritmo de Escalonamento Reconfigurável de Gangues
(RGSA - Reconfigurable Gang Scheduling Algorithm) (GÓES; MARTINS, 2004a; GÓES;
MARTINS, 2004b), que fará parte da nossa pesquisa.
O RGSA é um algoritmo que se baseia no algoritmo de escalonamento de gangues de
Ousterhout (OUSTERHOUT, 1982), o Gang Scheduling Algorithm (GSA). O RGSA se
diferencia do algoritmo de escalonamento de gangues de Ousterhout por possibilitar a
utilização de diferentes configurações de escalonamento em tempo de execução e que o
algoritmo se reconfigure automaticamente de acordo com as regras detalhadas no algoritmo. E
isso é importante pelo fato de existirem variações nas cargas de trabalho e nos sistemas de
computação, além do comportamento dinâmico dos sistemas de computação. Contudo, um
fator a se considerar é que quanto mais complicado ou quanto mais informação se necessitar
para a tomada de decisão da política de escalonamento, maior será o consumo dos recursos
que o escalonador está gerenciando. Dentre os recursos consumidos destacamos os EPs, as
memórias e a largura de banda da rede de interconexão ou do barramento utilizados para
conectar os EPs. O RGSA foi implementado utilizando simulação no ClusterSim (simulador
de escalonamento paralelo de tarefas em aglomerado de computadores) (GÓES; RAMOS;
MARTINS, 2004).
A principal vantagem do RGSA é o alto desempenho devido à flexibilidade e
adaptabilidade na execução das cargas de trabalho. Ele possui uma Camada de Controle de
Configuração (CCC) que permite que as configurações do escalonador sejam alteradas
dinamicamente em tempo de execução. Dessa forma, o RGSA é reconfigurado e adequado
com a configuração da política de escalonamento selecionada pelo algoritmo, dentre outras
configurações disponíveis, para cada carga de trabalho executada.
E citamos duas desvantagens como principais. A primeira é a necessidade da carga de
trabalho estar etiquetada, ou conter anotação (termo mais utilizado atualmente), antes de sua
17
execução. Para o RGSA, as anotações são os parâmetros de entrada que, neste caso, são as
características da carga de trabalho. A segunda desvantagem é a camada CCC não possuir
mecanismos de auto-adaptação.
Porém, o RGSA foi proposto utilizando as características ideais, ou seja, utilizando
sempre as melhores configurações para cada carga de trabalho. Sendo assim, uma
implementação real do RGSA, da maneira como foi originalmente concebido, não é uma
opção viável de implementação, visto que nem sempre conseguimos saber antecipadamente as
características das cargas de trabalho a serem executadas. E, para conseguirmos essas
informações, é necessário caracterizar e gerar as anotações da carga de trabalho. Esta é uma
das principais dificuldades em se implementar o RGSA num sistema de computação paralelo
real, pois a camada CCC precisa receber a carga de trabalho com as suas respectivas
anotações para que o RGSA possa configurar o escalonador com as melhores configurações
para esta carga para a execução da mesma.
1.2 Problema Motivador
A motivação dessa pesquisa teve origem na leitura da dissertação de mestrado
“Proposta e Desenvolvimento de um Algoritmo Reconfigurável de Escalonamento Paralelo de
Tarefas” (GÓES; MARTINS, 2004b) onde os problemas foram solucionados com simulação
usando o simulador ClusterSim. Nesta dissertação, o aluno propôs o RGSA, um algoritmo de
escalonamento de tarefas paralelas baseado no Gang Scheduling Algorithm (GSA) e que
utiliza conceitos de computação reconfigurável aplicados no algoritmo de escalonamento
paralelo de tarefas. Para tal, foi desenvolvido na pesquisa um simulador discreto por eventos
para validar o escalonador. O simulador desenvolvido para validar a proposta do RGSA,
simula também um ambiente paralelo de cluster, onde o escalonador foi simulado.
O escalonador RGSA possui a camada de controle de configuração (CCC) ideal ou
ótima. Isso porque o escalonador tem como premissa receber juntamente com a carga de
trabalho a ser executada no ambiente, uma anotação contendo informações das características
da carga de trabalho, a qual servirá como parâmetro de entrada da CCC. Esta anotação da
carga de trabalho faz com que a mesma seja executada com a melhor configuração disponível
no escalonador para a carga em questão. Assim, o RGSA considera que existe algum módulo
externo que executa o serviço de fornecer os valores corretos das características das cargas de
trabalho (anotações) ou simplesmente gere as anotações das cargas de trabalho corretamente.
Desta forma, essas anotações são utilizadas como parâmetros de entrada da CCC. Isso é a
18
condição ideal, porém é a principal dificuldade para se implementar o RGSA na prática, pois
a carga tem que ser analisada como um todo antes de ser executada; e isso acarreta em muita
sobrecarga para o RGSA.
O problema motivador do trabalho é, então, a dificuldade em se implementar a CCC
do RGSA utilizando como parâmetros de entrada a anotação com as informações necessárias
para escalonar a carga e obtidas com o mínimo de sobrecarga possível. Porém, um fator
importante a se considerar é que nos escalonadores reconfiguráveis existe essa dificuldade em
se obter um mecanismo que extráia as informações da carga de trabalho e reconfigure o
escalonador dinamicamente. Assim, o propósito desta pesquisa é a de se desenvolver uma
CCC mais realística, que nos proporcione a menor perda de desempenho possível e que esteja
preparada para ser implementada na prática.
1.3 Hipótese de Solução
Conforme citado anteriormente, o RGSA necessita que as cargas de trabalho
contenham anotações para que a CCC possa configurar o RGSA com as configurações mais
eficientes em termos de desempenho de escalonamento para a respectiva carga. Para tirar a
dependência do RGSA das cargas de trabalho conterem anotações, a nossa proposta de
solução é desenvolver um controle de configuração para escalonadores reconfiguráveis de
tarefas paralelas e incluí-lo no RGSA. Esse controle de configuração utilizará predição das
configurações, fundamentada no agrupamento e modelagem estatística das cargas de trabalho
executadas no passado para tomada de decisão. Assim, uma nova camada de controle de
configuração (CCC) para o RGSA será desenvolvida e ela será fundamentada na regularidade
temporal das cargas de trabalho. A solução vai se basear nas características das cargas de
trabalho que foram executadas e escalonadas no sistema de computação paralelo no passado
para que possamos utilizar como parâmetros de entrada para a CCC.
A hipótese de solução a ser testada é que as cargas de trabalho executadas nos
mesmos períodos e intervalos de tempo (no caso desta pesquisa dias da semana e horários)
apresentam alguma homogeneidade em termos de características ideais de execução e/ou
escalonamento em função de regularidade temporal das cargas de trabalho. Com isso
queremos mostrar que é possível escalonar cargas de trabalho futuras usando configurações
preditas a partir de um modelo produzido por agrupamento e modelagem estatística de cargas
de trabalho do passado.
19
Assim, extraímos informações de cargas de trabalho de um determinado período que
foram executadas em um sistema de computação paralelo. Depois, agrupamos e modelamos
essa carga de trabalho do passado utilizando análise estatística. A partir daí, executamos estas
cargas de trabalho modeladas utilizando simulação com o ClusterSim e extraímos
informações referentes a estas execuções. Com essas informações conseguimos predizer as
configurações mais indicadas para cada intervalo da carga. Após, extraímos informações de
cargas de trabalho de períodos posteriores deste mesmo sistema de computação utilizado. No
final, executamos a carga de trabalho mais recente utilizando as configurações preditas com a
carga de trabalho do passado.
1.4 Objetivos e Metas
Com base no problema citado anteriormente, o nosso objetivo principal ou geral é
propor e desenvolver um controle de configuração para escalonadores reconfiguráveis de
tarefas paralelas que utilize predição das configurações fundamentada em agrupamento e
modelagem estatística das cargas de trabalho executadas no passado. Para isso, iremos utilizar
o RGSA nesta pesquisa e iremos alterar sua camada de controle de configuração (CCC). Com
isso, utilizaremos como parâmetros de entrada para a tomada de decisão do escalonamento do
RGSA o horário de submissão de cada tarefa da carga de trabalho. Esta solução visa propor
uma versão do RGSA que seja mais próxima da realidade e que seja possível e viável de se
implementar em sistemas reais.
A nossa meta principal é, então, uma nova camada CCC do RGSA utilizando predição
das configurações fundamentada na análise, agrupamento e modelagem estatística das cargas
de trabalho executadas no passado. Desta forma, queremos implementar uma CCC baseada
em regularidade temporal que utilize rastros de cargas de trabalho reais executadas em
períodos de tempo diferentes para identificar as características dessas cargas. De posse dessas
informações das cargas referentes ao passado, a CCC pode tomar melhores decisões. Além
disto, propomos um novo mecanismo do RGSA de alteração de configurações da camada
CCC.
Como objetivos secundários temos: i) análise inicial do RGSA Original; ii) análise
inicial de caracterização de cargas de trabalho; iii) análise detalhada da camada CCC do
RGSA Original; iv) proposta de um mecanismo de alteração das configurações da camada
CCC do RGSA; v) aplicação de técnicas de otimização na proposta e desenvolvimento da
nova camada CCC do RGSA; vi) comparação da nossa CCC Proposta com a CCC Proposta
20
Ideal ou Ótima (que utiliza as configurações mais eficientes possíveis em termos de
desempenho para cada carga de trabalho).
1.5 Justificativa
A justifi cativa para o trabalho é que o escalonamento é importante para o
desempenho dos clusters e sistemas de computação paralelos em geral, pois é ele o
responsável por tomar as decisões a respeito da execução das tarefas. A nova proposta de
camada de controle de configuração (CCC) do RGSA, após sua implementação, poderá ajudar
nos estudos de melhoria na área de escalonamento paralelo de tarefas e no maior uso de
reconfiguração em software. Além disso, pode proporcionar maior qualidade nos resultados
produzidos e em pesquisas, pois pode reduzir bastante os tempos de execução das cargas de
trabalho nos sistemas de computação paralelos. Assim, isso será importante para as diversas
áreas do conhecimento que utilizam computação de alto desempenho, em especial
computação paralela, podendo proporcionar maior desempenho.
O escalonamento de tarefas paralelas é um dos fatores importantes para que o sistema
de computação paralelo possa apresentar um desempenho de execução satisfatório. Por isso,
estudos nesta área possuem sua importância para que os escalonadores sejam aprimorados e
para que, desta forma, os usuários de sistemas de computação paralelos possam se beneficiar
dessa evolução. Dentre os usuários beneficiados estão os de âmbito empresarial, profissional,
acadêmico e de aprendizado, envolvendo principalmente as empresas e as universidades.
O RGSA, como objeto desta pesquisa, produziu resultados de qualidade escalonando
tarefas no simulador ClusterSim. Além disso, o RGSA foi escolhido, porque tínhamos acesso
ao código fonte do escalonador e do simulador utilizado na verificação e testes do RGSA.
Também, por termos acesso ao próprio desenvolvedor da aplicação, que é vinculado ao nosso
laboratório de pesquisa. Outro fator importante a ressaltar é o fato de o RGSA ter sido
desenvolvido com o próprio ClusterSim. Como existe uma dificuldade grande em se
implementar a camada de controle de configuração (CCC) do RGSA, a proposta de uma nova
CCC mais simples passa a tornar a utilização do RGSA num ambiente real não simulado mais
próxima de se concretizar. Isso porque a caracterização da carga de trabalho usando
regularidade temporal passa a ser uma alternativa mais viável e realística do que a proposta
original.
Foram realizadas pesquisas em sites de busca e em publicações de eventos e
periódicos da área sobre escalonadores de tarefas paralelas e o uso de reconfigurabilidade
21
aplicado em escalonamento. Foram encontrados trabalhos relacionados com algumas das
áreas desta pesquisa, porém, os relacionados diretamente com todas as áreas da pesquisa
foram apenas os trabalhos (GÓES; MARTINS, 2003; GÓES; MARTINS, 2004a; GÓES;
MARTINS, 2004b). Este fato aumenta a importância da pesquisa.
Como relevância deste trabalho, podemos destacar a continuidade da pesquisa da
dissertação de mestrado “Proposta e Desenvolvimento de um Algoritmo Reconfigurável de
Escalonamento Paralelo de Tarefas” (GÓES; MARTINS, 2004b). Essa pesquisa foi realizada
no Laboratório de Sistemas Digitais e Computacionais (LSDC) do Programa de Pós-
Graduação em Engenharia Elétrica (PPGEE) da PUC Minas. Um dos trabalhos futuros da
pesquisa (GÓES; MARTINS, 2004b) é a implementação do RGSA em um ambiente real.
Assim, essa dissertação é uma etapa para permitir que a implementação do RGSA em um
ambiente real seja desenvolvida em algum trabalho futuro. Além disso, a possibilidade de se
implementar o RGSA num sistema de computação paralelo não simulado pode proporcionar a
realização de uma análise entre um ambiente de simulação (RGSA simulado utilizando o
ClusterSim) e um ambiente de experimentação real não simulado (RGSA implementado num
sistema de computação não simulado). Assim, pode ser realizada uma análise de desempenho
entre sistemas de computação simulados e não simulados. Outra análise que pode ser
realizada é a utilização de reconfigurabilidade em escalonadores de tarefas paralelas nos
sistemas de computação paralelos e do ganho que podemos alcançar com esse uso. Isso é
importante, pois o tempo gasto com a reconfiguração no escalonamento pode influenciar no
desempenho do próprio escalonamento.
1.6 Escopo
O escopo da pesquisa é o desenvolvimento de um controle de configuração para
escalonadores reconfiguráveis de tarefas paralelas fundamentado na predição das
configurações utilizando agrupamento e modelagem estatística da carga de trabalho executada
no passado. Com isso, mostraremos nesta pesquisa a alteração na camada de controle de
configuração (CCC) do RGSA originalmente concebida. Esta nova camada desenvolvida
possibilitará ao RGSA ser implementado mais facilmente em sistemas de computação reais.
Além disso, a versão do RGSA com a nova CCC poderá ser utilizada com o ClusterSim, o
qual é gratuito e disponível para download no site acadêmico do PPGEE da PUC Minas.
Assim, os alunos, pesquisadores ou profissionais da área poderão estudar e testar o RGSA
com suas próprias cargas de trabalho antes de implementá-lo em seu ambiente paralelo. Hoje
22
isso é possível, porém as cargas de trabalho precisam estar caracterizadas ou serem
caracterizadas antes de serem executadas pelo ClusterSim.
1.7 Organização do restante do texto
A organização deste documento segue a ordem descrita a seguir. No capítulo 2,
revisão bibliográfica, é apresentada a revisão da literatura de algumas das subáreas e os
assuntos que são importantes para o desenvolvimento da pesquisa. São elas: arquiteturas
paralelas, escalonamento de tarefas paralelas, escalonamento de gangues, Reconfigurable
Gang Scheduling Algorithm e principais trabalhos relacionados.
No capítulo 3 são apresentadas a proposta e o desenvolvimento do novo controle de
configuração para escalonadores reconfiguráveis de tarefas paralelas que será utilizado na
nova CCC Proposta do RGSA.
No capítulo 4 são apresentados os resultados obtidos nesta pesquisa após os testes
realizados com o novo controle de configuração da CCC Proposta do RGSA.
No capítulo 5, conclusão, são apresentadas as discussões dos resultados obtidos nesta
pesquisa, as principais contribuições e alguns possíveis trabalhos futuros.
Por fim são apresentadas as referências utilizadas para o desenvolvimento desta
pesquisa.
23
2 REVISÃO BIBLIOGRÁFICA
Neste capítulo é apresentada a revisão bibliográfica das áreas relevantes para nossa
pesquisa. Primeiramente é feita a revisão bibliográfica das arquiteturas paralelas. Em seguida,
escalonamento de tarefas paralelas. Logo após detalharemos dois tipos de escalonamento de
tarefas paralelas, o escalonamento de gangues (GSA) e o escalonamento reconfigurável de
gangues (RGSA). Por fim são apresentados os principais trabalhos relacionados.
2.1 Arquiteturas Paralelas
A taxonomia de Flynn de arquitetura de computadores engloba quatro modelos de
arquiteturas de computadores paralelos (FLYNN, 1966; FLYNN, 1972; ALMASI;
GOTTLIEB, 1994):
a) Single Instruction Single Data – SISD;
b) Single Instruction Multiple Data – SIMD;
c) Multiple Instruction Single Data – MISD;
d) Multiple Instruction Multiple Data – MIMD.
Estes modelos envolvem instruções e dados, podendo ser fluxos únicos ou múltiplos
de instruções sendo executadas utilizando fluxos únicos ou múltiplos de dados. Dentre esses
modelos de computadores paralelos da taxonomia de Flynn destacaremos o modelo de
computador paralelo MIMD dentre os demais, pois é o que iremos utilizar nesta pesquisa. No
modelo de arquitetura de computadores MIMD, vários Elementos de Processamento (EPs)
executam múltiplas instruções utilizando diferentes conjuntos de dados e códigos/rotinas
executáveis como carga de trabalho.
A classificação das arquiteturas paralelas do modelo MIMD pode ser dividida
basicamente em duas classes principais: os multiprocessadores e os multicomputadores.
Um multiprocessador é um computador paralelo composto de um conjunto de EPs que
compartilham uma mesma memória física e um mesmo espaço de endereçamento. Como
meio ou forma de comunicação são utilizadas variáveis compartilhadas em memória. Para a
comunicação são realizadas escritas e leituras nestas variáveis compartilhadas em sua
24
memória feitas pelos processos de uma mesma tarefa (ALMASI; GOTTLIEB, 1994;
BUYYA, 1999; HWANG; XU, 1998).
Já um multicomputador é aquele computador paralelo composto por nodos, sendo que
cada nodo possui sua própria memória física, a qual é independente dos demais nodos. Como
cada nodo possui sua própria memória física, eles não compartilham um mesmo espaço de
endereçamento. Para que ocorra a comunicação, um processo precisa trocar mensagens com
outro nodo por meio de uma rede de interconexão entre eles (BUYYA, 1999; HWANG; XU,
1998). A rede de interconexão pode ser simples e montada com uma rede local padrão
ethernet; ou ser mais complexa utilizando algum outro tipo de interconexão.
Nesta pesquisa, damos destaque para a arquitetura paralela de aglomerado de
computadores ou simplesmente clusters, nome pelo qual são mais conhecidos. Os clusters
fazem parte da classe dos multicomputadores. Um cluster possui todos os seus nodos
trabalhando coletivamente como um sistema único. A idéia é o usuário ter a sensação de estar
visualizando o cluster como uma Imagem de um Sistema Único (Single System Image - SSI).
Assim, o usuário mesmo estando logado em apenas um computador, teria a visão de todos os
serviços oferecidos pelo cluster. Cada nodo do cluster pode ser um SMP, uma estação de
trabalho ou um computador pessoal independente. Ou seja, os desktops ou computadores
pessoais que utilizamos normalmente em casa ou no trabalho podem fazer parte de um
multicomputador deste porte. Os clusters possuem um baixo custo financeiro, visto que são
construídos utilizando componentes de hardware mais baratos e encontrados facilmente em
qualquer loja acessível a todas as pessoas (chamados de hardware do tipo commodity-off-the-
shelf - COTS) e software livre disponível (BUYYA, 1999; HWANG; XU, 1998; ALMASI;
GOTTLIEB, 1994). Apesar do baixo custo, eles podem prover um poder de processamento
elevado dependendo da forma com que aplicações utilizadas são escritas e das políticas de
escalonamento utilizadas.
2.2 Escalonamento de Tarefas Paralelas
O escalonamento de tarefas é um problema no qual um algoritmo procura alocar, ao
longo do tempo, uma carga de trabalho a uma arquitetura. A carga de trabalho é composta por
uma ou mais tarefas. Nos casos de arquiteturas não paralelas, que são os casos mais
comumente encontrados, a arquitetura normalmente é composta por um único processador ou
um processador com um único núcleo. Mas quando falamos em escalonamento paralelo, a
diferença é que o escalonador procura alocar as tarefas ao longo do tempo aos processadores
25
da arquitetura paralela. Nele, os processadores podem ser compartilhados por meio de
compartilhamento de espaço e compartilhamento de tempo. O compartilhamento de espaço
acontece com a divisão ou o compartilhamento dos espaços de memória e demais recursos
computacionais existentes no computador. Já o compartilhamento de tempo, ocorre na divisão
de fatias de tempo de processamento entre os diversos processos que estão sendo executados
em um determinado momento em uma arquitetura computacional. Esses tipos de
compartilhamento utilizam mecanismos amplamente independentes ou ortogonais,
possibilitando uma combinação entre eles (FEITELSON, 1997; HWANG; XU, 1998). E essa
combinação tem impacto direto no desempenho do sistema computacional.
No escalonamento paralelo existem dois tipos principais: estático e dinâmico
(CAMPOS, 1999; EL-REWINI; ALI; LEWIS, 1995; FEITELSON, 1997; KWOK; AHMAD,
1999; YAMIN, 2001).
No escalonamento estático, o escalonador faz o mapeamento das tarefas de maneira a
atribuir tarefas aos EPs. Isso no intuito de minimizar o tempo total de execução das tarefas.
Contudo, isso é feito antes do início da execução, ou seja, em tempo de compilação. Dessa
forma, após o início do processamento, as tarefas permanecem nos processadores aos quais
foram alocadas, até que a execução paralela finalize. Isso caracteriza como não-preemptivas
as estratégias de escalonamento estático. Assim, é necessário que a política de escalonamento
tenha algum tipo de conhecimento com relação às tarefas para não diminuir o desempenho da
execução do sistema. Caso o algoritmo de escalonamento não tenha um bom conhecimento
sobre alguns itens como os citados logo abaixo, isto fará com que o escalonador não tenha um
bom desempenho. Exemplos destes itens são:
a) Tipo das tarefas;
b) Tempo de execução;
c) Relações de dependência;
d) Padrões de comunicação entre as mesmas.
A decisão de escalonamento no caso do escalonamento estático é geralmente
centralizada, não se adaptando ao estado atual ou futuro do ambiente de execução (CAMPOS,
1999; EL-REWINI; ALI; LEWIS, 1995; KWOK; AHMAD, 1999; YAMIN, 2001). É como
se tivéssemos uma lista de pares formada por tarefas e EPs, sendo que esta lista é gerada antes
do início da execução das tarefas. Só que isto não é o ideal no mundo real, pois a mesma
26
política não consegue satisfazer aos requisitos de qualidade, de custo e de tempo de execução
para todas as possíveis combinações de carga de trabalho existentes.
Para o escalonamento paralelo dinâmico, poucas suposições podem ser feitas sobre as
tarefas e os processos antes do início da execução, assim sendo, as tomadas de decisão para o
escalonamento devem ser realizadas somente em tempo de execução. A idéia basicamente é a
de se fazer o ordenamento e a alocação dos processos de uma determinada tarefa durante a
execução da mesma, tendo como meta ou fim, não apenas a redução do tempo de execução da
tarefa, mas também a minimização da sobrecarga de escalonamento. Como sobrecarga de
escalonamento, podemos mencionar o tempo gasto para coleta de informações, para a
distribuição ou até mesmo para a migração das tarefas. Isso mostra que o escalonamento pode
ser preemptivo, distribuído e/ou adaptativo (CAMPOS, 1999; FEITELSON, 1997; KWOK;
AHMAD, 1999; YAMIN, 2001). Voltando ao exemplo da lista de pares, é como se esta lista
fosse sendo formada e atualizada conforme algumas regras pré-estabelecidas a fim de
distribuir as tarefas aos EPs.
2.3 Escalonamento de Gangues
O Gang Scheduling Algorithm (GSA) ou simplesmente escalonamento de gangues, foi
o algoritmo base para o desenvolvimento do RGSA. O GSA, que será detalhado
posteriormente, foi primeiramente desenvolvido e apresentado por Ousterhout
(OUSTERHOUT, 1982). Com o nome inicial de co-escalonamento, teve como objetivo
principal o uso eficiente da espera ocupada das tarefas de sincronização de grão fino. Assim, a
idéia é de se utilizar melhor o tempo em que um processo estiver em espera ocupada
aguardando algum evento ou resposta acontecer. O escalonamento de gangues é uma
combinação de três características (FEITELSON, 1997):
a) Os processos devem ser agrupados em gangues (o sentido de gangue aqui se refere
a processos com alguma característica semelhante: I/O bound, CPU bound,
processos de mesma tarefa, processos que se comunicam entre si, dentre outras);
b) Os processos de uma tarefa executam simultaneamente em processadores distintos;
c) Todos os processos de uma gangue são interrompidos e re-escalonados ao mesmo
tempo, utilizando-se compartilhamento de tempo.
27
Partindo dessas premissas, percebemos que casos de grupos de processos (gangues)
que se comunicam com muita freqüência devem ser agrupados em uma gangue visto que
serão todos escalonados ao mesmo tempo. Normalmente, todos os processos de uma tarefa
são considerados uma gangue (FEITELSON, 1997).
O escalonamento de gangues possui como vantagens principais:
a) Prover tempo de resposta interativo para tarefas com baixo tempo de execução, por
meio de preempção;
b) Evitar que tarefas com alto tempo de execução monopolizem os processadores;
c) Aumentar a utilização do sistema na alocação de recursos (FEITELSON, 1997;
JETTE, 1997);
d) Não necessitar de uma estimativa do tempo de término de uma tarefa (ZHANG,
2000);
e) As tarefas podem ser iniciadas sem ter que esperar que todos os processadores
requeridos sejam desocupados (JETTE, 1997).
O escalonamento de gangues possui como desvantagens principais:
a) A característica de preempção aumenta a sobrecarga na troca de contexto e pode
reduzir o desempenho da cache (FEITELSON, 1997)
b) Possui necessidade de memória e disco adicional devido a várias tarefas
compartilharem os mesmos processadores (BATAT; FEITELSON, 2000)
c) Necessidade de fragmentação de tarefas (FRANKE, 1999; ZHOU, 1999)
d) Os processadores ficam ociosos (escalonamento de gangues restrito) no momento
que os processos realizam I/O ou comunicação bloqueante, (WISEMAN;
FEITELSON, 2003).
2.4 Reconfigurable Gang Scheduling Algorithm
Iremos detalhar um pouco sobre reconfigurabilidade e posteriormente sobre o
algoritmo Reconfigurable Gang Scheduling Algorithm (RGSA) (GÓES; MARTINS, 2004a),
porém, explicaremos primeiramente os conceitos de computação reconfigurável.
Quando comparamos os dispositivos de hardware fixo ou não programáveis (solução
ou paradigma de hardware) com os microprocessadores ou dispositivos programáveis
28
(solução ou paradigma de software), chegamos a algumas conclusões. O hardware fixo
produz um desempenho superior ao dos microprocessadores, porém, como seu
comportamento lógico é único, possui menor flexibilidade. Já com os microprocessadores
acontece o inverso, pois produzem um desempenho menor, porém possuem uma maior
flexibilidade (MARTINS et al, 2003).
Devido ao contraste entre estes dois paradigmas, criou-se um terceiro paradigma
chamado solução ou paradigma em hardware reconfigurável. Esse novo paradigma visa, além
de tudo, buscar unir as vantagens das duas soluções descritas anteriormente, como também
eliminar as suas desvantagens. Dessa forma, possibilita-se um maior desempenho e
flexibilidade unidos em uma mesma solução ou em um mesmo dispositivo (MARTINS et al,
2003).
Assim utilizou-se de conceitos de computação reconfigurável no desenvolvimento do
RGSA a fim de implantar a flexibilidade e adaptabilidade dinâmica no escalonador.
O RGSA é uma adaptação do algoritmo GSA utilizando conceitos de computação
reconfigurável. Um algoritmo que utiliza conceitos de reconfiguração se baseia em três
camadas, assim como mostrado na Figura 1, sendo a primeira chamada de Camada Básica
(CB), a segunda de Camada Reconfigurável (CR) e a terceira de Camada de Controle de
Configuração (CCC). A CB é representada pelas estruturas de dados e conjuntos de quadros.
A CR é aquela que armazena as possíveis configurações da CB. Assim a CCC irá, num
determinado momento preencher cada um dos quadros do conjunto de quadros da CB com
uma configuração da CR. A CCC controla dinamicamente essas configurações dos quadros de
acordo com alguns parâmetros de entrada.
No RGSA os parâmetros de entrada são: o tempo de execução (que pode ser alto ou
baixo), o grau de paralelismo (podendo ser alto ou baixo) e o grau de predominância (valores
60%, 80% ou 100%). O tempo de execução alto é aquele cujo total de instruções executadas
pela tarefa seja igual a 1 bilhão de instruções, enquanto as tarefas com baixo tempo de
execução executam 100 milhões de instruções. Por outro lado, o grau de paralelismo de uma
tarefa é considerado alto se a quantidade de processos da tarefa for maior que 1/4 da
quantidade de processadores do sistema computacional. Caso a quantidade de processos seja
menor ou igual à 1/4 da quantidade de processadores do sistema computacional, o grau de
paralelismo é considerado baixo. Já o grau de predominância da carga é o percentual da
quantidade de tarefas da carga com grau de paralelismo alto, variando entre os valores 60%,
80% ou 100%. Essa métrica foi utilizada nos experimentos realizados para a avaliação de
desempenho do RGSA.
29
Figura 1 - Modelo de Algoritmo Reconfigurável
Fonte: (GÓES; MARTINS, 2004b)
No caso do RGSA, a CB é uma camada contendo uma fila implementada para que as
tarefas que chegam ao ambiente que possui essa política de escalonamento implementada
entrem nesta fila de espera para aguardar o momento de serem executadas. A CR contem
algumas configurações dos quadros da CB como: formas de empacotamento (primeiro
encaixe ou melhor encaixe), esquemas de desfragmentação (unificação de fatias e
escalonamento alternativo), políticas de remoção da fila de espera (Primeiro a Entrar Primeiro
a ser Servido ou Menor Tarefa Primeiro), níveis de multiprogramação (limitado ou ilimitado).
As formas de empacotamento são as configurações que alocam as tarefas aos EPs. O esquema
de desfragmentação é a forma como as tarefas são redistribuídas entre as fatias de tempo do
escalonador para evitar a fragmentação. Já a política de remoção da fila de espera é composta
pelas regras que o RGSA utiliza para remover as tarefas da fila de espera e colocar em
execução. Por fim, o nível de multiprogramação é a quantidade de fatias de tempo que o
algoritmo utiliza para realizar o escalonamento.
Por fim, a CCC é implementada como uma tabela que sabe, baseada em alguns
parâmetros de entrada que foram citados anteriormente, qual a melhor configuração para a
execução da tarefa atual. Assim, a CCC vai configurando dinamicamente para cada tarefa ou
30
conjunto de tarefas em questão as melhores configurações para aquele escopo atual. A Figura
2 mostra como exemplo uma das configurações possíveis para o RGSA.
Figura 2 - Uma das configurações do RGSA
Fonte: (GÓES; MARTINS, 2004b)
2.5 Principais Trabalhos Relacionados
Na revisão bibliográfica realizada encontramos alguns trabalhos relacionados. Em se
tratando de trabalhos relacionados com escalonadores de tarefas, teremos uma infinidade de
trabalhos correlatos.
Já se formos citar trabalhos sobre escalonadores reconfiguráveis, encontramos um que
possui alguma semelhança. Em (MONTANA; HUSSAIN; VIDAVER, 2007), foi
desenvolvido e proposto o Vishnu, um escalonador reconfigurável baseado em algoritmo
genético para resolver problemas clássicos de escalonamento e não problemas no contexto de
computação e escalonamento de tarefas paralelas. Os problemas resolvidos pelo Vishnu são
Traveling Salesman Problem, Job-Shop Scheduling Problem e Vehicle Routing Problem with
31
Time Windows. Ou seja, não são problemas de escalonamento de tarefas paralelas em sistemas
de computação paralelos.
Com relação à reconfiguração, além do (MONTANA; HUSSAIN; VIDAVER, 2007)
descrito anteriormente, encontramos outro trabalho semelhante ou parecido. Este trabalho é
descrito em (FREITAS et al, 2008) e é aplicado em redes de sensores e utiliza suporte a
reconfiguração para escalonamento de serviços. Apesar de escalonar tarefas, o foco são os
serviços. Com isso, o escalonador descrito em (MONTANA; HUSSAIN; VIDAVER, 2007) é
executado em um sistema de rede de sensores e não em um sistema de computação paralelo.
Outra diferença é que ele escalona tarefas para priorizar os serviços da rede de sensores e não
para questões de desempenho das tarefas que estão sendo executadas.
Encontramos vários trabalhos, como os descritos em (PAN; WELLS, 2008;
CLEMENTE. et AL, 2008), que utilizam reconfiguração em escalonamento de tarefas
utilizando reconfiguração em hardware reconfigurável FPGA e não reconfiguração em
software como no nosso trabalho.
O único escalonador reconfigurável de tarefas paralelas que encontramos foi o RGSA.
E os únicos trabalhos diretamente relacionados com escalonamento reconfigurável de tarefas
paralelas em software foram os ligados à dissertação de mestrado “Proposta e
Desenvolvimento de um Algoritmo Reconfigurável de Escalonamento Paralelo de Tarefas”
(GÓES; MARTINS, 2004b), entre eles (GÓES; MARTINS, 2003; GÓES; MARTINS,
2004a). Além disso, outro trabalho relacionado é a “Técnica de Caracterização de Cargas de
Trabalho de Supercomputadores” descrita em (SANTOS; SILVA; GÓES, 2009) que foi
utilizada para a caracterização das cargas de trabalho do passado para utilizarmos na tomada
de decisão da predição das configurações do RGSA mais indicadas para cada uma das cargas
de trabalho.
32
3 PROPOSTA DE SOLUÇÃO
Neste capítulo apresenta-se a proposta de solução da pesquisa. Inicialmente
detalhamos o contexto referente à proposta de solução. Posteriormente, é feita uma análise do
RGSA originalmente concebido e de sua respectiva camada de controle de configuração
(CCC Original). Ao final detalhamos a proposta de solução com a alteração da CCC do
RGSA e fazemos as considerações finais do capítulo.
3.1 Contexto da Proposta de Solução
Como foi apresentado e justificado anteriormente na introdução, o escalonador
reconfigurável de tarefas paralelas escolhido para ser utilizado nesta pesquisa foi o
Reconfigurable Gang Scheduling Algorithm (RGSA).
O algoritmo original do escalonador reconfigurável de tarefas RGSA possui uma
Camada de Controle de Configuração (CCC) que é a responsável por configurar o
escalonador com a configuração mais indicada para a carga de trabalho. A carga de trabalho é
submetida ao computador paralelo e o RGSA a recebe e a coloca em uma fila de espera. Cada
carga de trabalho precisa estar anotada com algumas informações citadas a seguir para que o
RGSA possa interpretar a informação contida nesta anotação e possa configurar o escalonador
com uma das configurações disponíveis. Para o caso do RGSA, a anotação precisa conter as
seguintes informações, como explicado na seção 2.4:
a) Tempo de execução: alto ou baixo;
b) Grau de paralelismo: alto ou baixo;
c) Grau de predominância: 60%, 80% ou 100%.
De posse dessas informações das anotações da carga, a CCC faz uma avaliação e
configura o RGSA com a configuração mais adequada de escalonamento disponível no
escalonador para a carga.
Pelo fato do RGSA necessitar da anotação da carga para que o escalonador funcione
na prática e assim escalonamento seja realizado, temos duas estratégias possíveis. Uma das
estratégias é a utilização de caracterização explícita e a outra é a utilização de alguma forma
de predição. A primeira estratégia seria o desenvolvimento de um módulo de extração de
33
anotações ou caracterização explícita das cargas. Esse módulo deve fazer a extração das
informações necessárias da carga para que o RGSA se reconfigure com a melhor configuração
para a respectiva carga, assim que a mesma chegar ao computador paralelo. Utilizamos dessa
forma, dados do presente para extrair a anotação. A segunda estratégia é o desenvolvimento
de um mecanismo de predição ou escolha das configurações que não dependa da
etiquetagem/anotação padrão do RGSA para ser incorporado ao algoritmo. Assim, utilizamos
alguma informação do passado para isso.
Com relação à primeira solução, a criação de um módulo de caracterização explícita
ou extração de anotações das cargas de trabalho utilizando dados da carga que acabou de
chegar, não é uma tarefa simples e trivial. Temos uma alta complexidade e um tempo alto de
extração de informações sobre as cargas que chegam ao RGSA para serem executadas. Assim
que a carga chega à fila de espera, este módulo deve extrair informações a respeito da carga
para anotá-la com as informações de que a CCC do RGSA necessita para poder configurá-lo
mais eficientemente. E o ideal é que esta extração e anotação forneçam o resultado
instantaneamente para não gerar sobrecarga no escalonador e para que o escalonador possa
adequar a carga e priorizá-la de acordo com suas características.
Já a segunda solução, um mecanismo de predição ou escolha das configurações, ao
invés da utilização da anotação da carga para poder realizar a escolha da configuração ideal
do RGSA, podemos utilizar outro mecanismo. Este mecanismo pode se basear em
informações extraídas previamente a partir de rastros de execuções passadas da carga. Com
isso, pode-se gerar um preditor que será utilizado como base para realizar o escalonamento.
Portanto, devido ao fato da alta complexidade e do alto tempo para anotar as cargas de
trabalho, optamos pela segunda opção de solução para pesquisarmos e desenvolvermos um
novo mecanismo de predição ou escolha das configurações para o RGSA. Desta forma,
incorporaremos na CCC do RGSA um novo mecanismo preditor das configurações do
escalonador reconfigurável para que as cargas de trabalho possam ser executadas de maneira
rápida e eficiente.
3.2 Análise da Camada de Controle de Configuração Original
Uma das características dos algoritmos reconfiguráveis, em especial o RGSA, que os
tornam eficientes é o seu mecanismo de adaptação às cargas (GÓES; MARTINS, 2004b). Ou
seja, quanto melhor for a predição da configuração ideal ou da configuração mais indicada,
mais eficiente será o algoritmo. E este mecanismo precisa ser bastante eficaz para que os
34
algoritmos em questão possam usufruir de todo o seu potencial. Um mecanismo de predição
de carga ideal deve escolher configurações que sejam eficientes e deve possuir alguma forma
de adaptação ou aprendizado. E devem analisar e levar em consideração o fator overhead para
essas alterações também. Com isso, eles vão alterando as configurações de acordo as
variações das cargas de trabalho de acordo com a necessidade. Pelo fato de nem sempre
possuírem um mecanismo ideal de adaptação às cargas, os algoritmos em questão, em sua
maioria, são implementados em simuladores com algumas simplificações. Por isso,
procuramos pesquisar e propor uma forma de implementar um mecanismo de predição de
configuração para os algoritmos reconfiguráveis de escalonamento paralelo de tarefas.
Nesta pesquisa utilizamos o RGSA pela qualidade dos resultados que ele mostrou
(GÓES; MARTINS, 2004a; GÓES; MARTINS, 2004b) e pelo acesso tanto ao código fonte
do algoritmo do escalonador quanto ao código fonte do ClusterSim, o simulador para o qual
ele foi desenvolvido, os quais são abertos.
Figura 3 - Representação simplificada do RGSA Original
Fonte: Elaborada pelo autor
Uma representação simplificada do escalonador de tarefas paralelas utilizando o
algoritmo RGSA Original é mostrada na Figura 3. O RGSA possui uma Camada de Controle
de Configuração (CCC) que é a parte do algoritmo que tem a função de configurar o
escalonador com as configurações mais adequadas para cada uma das cargas ou sub-cargas
que chegam. A CCC do RGSA Original tem como pré-requisito receber, juntamente com a
tarefa ou conjunto de tarefas, a etiqueta com informações detalhadas desta sub-carga. Com
essa informação, o RGSA Original associa na CCC a(s) tarefa(s) com as configurações mais
indicadas de acordo com as características da(s) mesma(s). E o escalonador vai executando as
35
tarefas com as configurações que a CCC repassa como sendo as melhores para aquela
etiqueta/sub-carga. Contudo, obter antecipadamente informações detalhadas das tarefas para
etiquetá-las não é um trabalho simples e rápido de se realizar antes da execução da carga de
trabalho.
Por isso, nessa pesquisa desenvolvemos uma solução diferente da originalmente
concebida para o RGSA, que não dependa da etiquetagem das cargas. Isso, pois a escolha da
melhor configuração para uma determinada carga é uma tarefa bastante difícil, visto que é um
problema com ordem de complexidade exponencial.
3.3 Proposta de Solução
A proposta de solução é se utilizar uma outra forma ou maneira de classificar a carga
ao invés de utilizar a anotação, ou etiqueta, da carga. Assim, queremos criar um mecanismo
de controle de configurações mais simples, rápido e eficaz de pré-classificar a carga baseada
no momento em que a carga chega à fila de recebimento (fila de espera) do escalonador
RGSA. Com isso, o que queremos é tirar a dependência de algum módulo interno ou externo
ao algoritmo reconfigurável RGSA, o qual seja responsável pela anotação das cargas de
trabalho submetidas ao escalonador.
A proposta de solução desta pesquisa é um controle de configuração para
escalonadores reconfiguráveis de tarefas paralelas que não necessite extrair e analisar dados
da carga de trabalho que está chegando para escalonar eficientemente as suas tarefas. Este
controle está sendo proposto inicialmente para o RGSA com a alteração da camada de
controle de configuração (CCC) do RGSA Original, mas pode ser implementado em outros
escalonadores reconfiguráveis de tarefas paralelas futuramente. Com essa alteração, a CCC
não necessitará mais que as cargas de trabalho submetidas estejam anotadas para escalonar as
tarefas. Assim, como mostrado na Figura 4, o que queremos é introduzir na CCC Original um
método Preditor, que não precise receber a anotação das cargas de trabalho submetidas.
36
Figura 4 - Proposta de solução para a CCC do RGSA - RGSA com CCC Proposta
RGSA
Tarefa 1Escalonador Paralelo
de Tarefas
Computador Paralelo
Fila de
Recebimento
de Tarefas
Tarefa N...
CCC com
PREDITOR
Configuração
Fonte: Elaborada pelo autor
A proposta da nova camada CCC tem como base agrupamento de dados e modelagem
estatística fundamentada na execução anterior das cargas de trabalho para tomar as decisões e
realizar a predição das configurações para o RGSA. Ou seja, o RGSA por meio do preditor
vai se basear na regularidade temporal das cargas de trabalho a serem executadas como
mostrado na Figura 5. Baseado em experimentos preliminares, constatamos que as cargas de
trabalho analisadas nesta pesquisa possuem características de regularidade temporal. O que
queremos dizer com isso é que podemos dividir as cargas de trabalho em espaços de tempo de
acordo com a temporalidade utilizada e com a regularidade das cargas. Portanto, o que
queremos mostrar é que as cargas executadas em determinado intervalo de tempo são
semelhantes às executadas em outro determinado intervalo de tempo futuro. E com isso,
implementar um mecanismo eficiente de predição das cargas para a CCC do RGSA que se
baseará em regularidade temporal das cargas de trabalho.
Figura 5 - Exemplo de Regularidade Temporal de cargas de trabalho
Fonte: Elaborada pelo autor
37
Em computadores paralelos de um modo geral, o comportamento de uma carga de
trabalho ao longo de um período de tempo é similar ao comportamento do período seguinte,
desde que seja constatada regularidade na carga (SANTOS; SILVA; GÓES, 2009). Já que
existe certa regularidade no comportamento das cargas executadas em um computador
paralelo, é possível predizer como será a carga executada no futuro. Com isso, conforme
mostrado na Figura 5, se soubermos que as tarefas de determinado computador paralelo
podem ser divididas em intervalos, e se conseguirmos prever o intervalo de uma determinada
tarefa, podemos configurar o escalonador com as configurações mais otimizadas disponíveis
ou adequadas para este conjunto de tarefas. Assim, o que propomos é utilizar a temporalidade
com período de tempo divididos em intervalos e fundamentada na média dos N períodos
anteriores da carga. Portanto, queremos mostrar que as cargas executadas em um determinado
computador paralelo em um determinado intervalo de um período possuem características
parecidas com às das cargas executadas neste mesmo intervalo de tempo de um período
posterior neste mesmo computador paralelo.
Esta solução proposta analisa as características das cargas de trabalho que foram
executadas e escalonadas no sistema de computação paralelo no passado utilizando as
configurações disponíveis do escalonador por meio de modelagem estatística. Depois disso, é
selecionada a melhor configuração por intervalo do período para que possamos utilizar como
parâmetro de entrada para a CCC Proposta utilizar no futuro utilizando simulação. A hipótese
de solução a ser testada é a de que as cargas de trabalho executadas nos mesmos períodos e
intervalos de tempo apresentam alguma homogeneidade em termos de características ideais de
execução e/ou escalonamento. Desta maneira, queremos mostrar que as cargas de trabalho
executadas em alguns dos sistemas de computação paralelos do mundo possuem
características de regularidade temporal e com isso configurar o escalonador de tarefas
paralelas para que possam executar essas cargas de trabalho com as configurações mais
adequadas.
38
Quadro 1 - Exemplo de temporalidade com período de uma semana e intervalo em horas
da semana
Domingo Segunda Terça Quarta Quinta Sexta Sábado
0 24 48 72 96 120 144
1 25 49 73 97 121 145
2 26 50 74 98 122 146
3 27 51 75 99 123 147
... ... ... ... ... ... ...
23 47 71 95 119 143 167
Fonte: Dados da pesquisa
Então, a proposta é extrair informações de cargas de trabalho de N períodos contínuos
que foram executadas por supercomputadores ou sistemas de computação paralelos reais.
Assim, agrupamos essa carga composta por N períodos em intervalos de período, assim como
no exemplo do Quadro 1. Com as cargas dos N períodos agrupadas e disponíveis neste
formato, extraímos as médias aritméticas por intervalo de período, gerando uma carga
sintética assim como exemplo da Figura 6. Este tipo de arquivo é chamado de arquivo de
workload (extensão .WKL).
Figura 6 - Parte de arquivo sintético .WKL com dados de um intervalo do dia 0 de uma
semana e das horas 0 a 7
Fonte: Adaptado de (THE STANDARD WORKLOAD FORMAT, 2 011)
Em um arquivo .WKL, como mostrado na Figura 6, a (i) primeira coluna representa o
dia e a hora (como exemplo, na primeira linha, D-0-0-0 representa D-0 sendo dia 0; e 0-0
representa hora de 0 a 0).
As (ii) segunda, (iii) terceira, (iv) quarta e (v) quinta colunas representam,
respectivamente, as probabilidades em percentuais de processos com: (ii) alto nível de
paralelismo e alto tempo de execução; (iii) alto nível de paralelismo e baixo tempo de
execução; (iv) baixo nível de paralelismo e baixo tempo de execução; (v) baixo nível de
39
paralelismo e alto tempo de execução. Essas colunas (ii, iii, iv e v) são calculadas com base
nas colunas (vi, vii, viii, ix, x, xi ) citadas a seguir.
A (vi) sexta coluna representa o número de tarefas submetidas. Já as (vii) sétima, (viii)
oitava e (ix) nona colunas representam respectivamente os números de processos submetidos
por tarefa: (vii) mínimo; (viii) médio; e (ix) máximo. Por fim, as três últimas colunas
representam respectivamente os tempos de execução das tarefas: (x) mínimo; (xi) médio; e
(xii) máximo.
O percentual “baixo nível de paralelismo” presente nas colunas (ii) e (iii) indica a
probabilidade de uma tarefa possuir entre “mínimo” (coluna vii) e “médio” (coluna viii)
número de processos. Já o percentual “alto nível de paralelismo” presente nas colunas (iv) e
(v) indica a probabilidade de uma tarefa possuir entre “médio” (coluna viii) e “máximo”
(coluna ix) número de processos.
Referente aos percentuais das tarefas “baixo tempo de execução” presente nas colunas
(iii) e (iv), estes indicam a probabilidade de uma tarefa possuir o tempo de execução entre
“mínimo” (coluna (x)) e “médio” (coluna (xi)). Enquanto o percentual “alto tempo de
execução” nas colunas (ii) e (v) representa a probabilidade de uma tarefa possuir o tempo de
execução entre “médio” (coluna (xi)) e “máximo” (coluna (xii)).
Para geração dos arquivos .WKL utilizados neste trabalho e que representam a
caracterização de cargas de trabalho, utilizamos a Técnica de Caracterização de Cargas de
Trabalho de Supercomputadores descrita em (SANTOS; SILVA; GÓES, 2009).
A partir daí realizamos a predição da carga utilizando simulação com o ClusterSim, ou
seja, executamos estas cargas de trabalho sintetizadas em intervalos de um período com todas
as combinações de configurações que o RGSA possui. Depois disso, extraímos as
características destas cargas de trabalho referentes a esta execução. Ao final, extraímos
informações de cargas de trabalho de períodos posteriores do mesmo sistema de computação
utilizado. Assim, no próprio ClusterSim, executamos a carga de trabalho mais recente
utilizando como parâmetros de entrada para a CCC Proposta do RGSA as características das
cargas de trabalho mais antigas. Para concluir, analisamos o desempenho da execução da
CCC Proposta.
As opções de configuração utilizadas no RGSA Original são 12 (doze) conforme
mostrado no Quadro 2. Com relação à segunda coluna deste Quadro 2, “Política Remoção
Fila”, quando utilizamos o nível de multiprogramação ilimitado (tamanho da fila de execução
infinita), a política de remoção da fila de espera não se aplica tendo em vista que não temos
fila de espera.
40
Quadro 2 - Configurações do RGSA Original
Configuração Política
Remoção Fila Esquema de Desfragmentação
Esquema de Empacotamento
Nível de Multiprogramação
Configuração 01 FCFS Unificação de Fatias Melhor Encaixe Limitado
Configuração 02 FCFS Escalonamento Alternativo Melhor Encaixe Limitado
Configuração 03 SJF Unificação de Fatias Melhor Encaixe Limitado
Configuração 04 SJF Escalonamento Alternativo Melhor Encaixe Limitado
Configuração 05 N/A Unificação de Fatias Melhor Encaixe Ilimitado
Configuração 06 N/A Escalonamento Alternativo Melhor Encaixe Ilimitado
Configuração 07 FCFS Unificação de Fatias Primeiro Encaixe Limitado
Configuração 08 FCFS Escalonamento Alternativo Primeiro Encaixe Limitado
Configuração 09 SJF Unificação de Fatias Primeiro Encaixe Limitado
Configuração 10 SJF Escalonamento Alternativo Primeiro Encaixe Limitado
Configuração 11 N/A Unificação de Fatias Primeiro Encaixe Ilimitado
Configuração 12 N/A Escalonamento Alternativo Primeiro Encaixe Ilimitado * Legenda: FCFS - Primeiro a Entrar Primeiro a ser Servido (First Come First Served); SJF - Tarefa Menor Primeiro (Short Job First); Fonte: Adaptado de (GÓES; MARTINS, 2004b)
Sintetizando, o que propomos é realizar a predição das configurações mais indicadas
para a carga utilizando agrupamento e modelagem estatística da forma descrita e mostrada na
Figura 7 e separada em 2 fases detalhadas a seguir: Fase de Predição e Fase de Execução.
41
Figura 7 - Fluxo de geração da CCC Proposta para uma carga, composto pelas Fases de
Predição e de Execução
Escolha das Configurações pelo
RGSA Proposto a cada intervalo
1.Carga Bruta de
N Períodos 3.Carga Sintética
de 1 Período
separada em X
intervalos de
reconfiguração
(extraída ítem1)
4.Execução da
Carga Sintética 3 -
Configuração 1
4.Execução da
Carga Sintética 3 -
Configuração Y
...
5.Geração da
CCC Proposta por
intervalo do período
baseada na
execução ítem 4
6.Carga Bruta
do Período
posterior a ser
escalonado
8.Execução da
Carga Bruta 6 -
Configuração Y
...
7.Execução da
Carga Bruta 6 –
RGSA Proposto
Fase de Predição
Fase de Execução
8.Execução da
Carga Bruta 6 -
Configuração 1
2.Agrupamento
e Modelagem
Estatística
Fonte: Elaborada pelo autor
A Fase de Predição das configurações é mostrada na 1ª parte do fluxo da Figura 7. No
item 1 extraímos os dados analíticos referentes aos N períodos de cargas de trabalho
submetidas ao computador paralelo. No item 2, de posse desses dados descritos no item 1,
geramos cargas sintéticas com o agrupamento desses N períodos subdividindo-os em
intervalos utilizando modelagem estatística e levando em consideração a média dos dados dos
N períodos em questão. A etapa do item 2 é gerada utilizando a técnica de caracterização de
cargas de trabalho descrita em (SANTOS; SILVA; GÓES, 2009). Com isso, geramos a carga
sintética do item 3. Então, já no item 4, executamos esta carga sintética com cada uma das Y
configurações fixas disponíveis no RGSA mostradas no Quadro 2 e para cada um dos X
intervalos do período. Após isso, no item 5, geramos a configuração para a CCC Proposta do
RGSA para cada intervalo do período como sendo uma tabela contendo o intervalo do período
e a configuração mais indicada para o determinado intervalo assim como mostrado no Quadro
3. O exemplo abaixo retrata um período de 1 semana e o intervalo em horas da semana.
42
Quadro 3 - Exemplo de tabela de configurações da nova CCC Proposta para o RGSA
com intervalos em horas da semana e período de 1 semana
Hora da Semana Melhor Configuração
0 Configuração 05
1 Configuração 01
2 Configuração 12
3 Configuração 08
... ...
166 Configuração 11
167 Configuração 11 Fonte: Elaborada pelo autor
Na 2ª parte do fluxo da Figura 7, temos a Fase de Execução. No item 6, extraímos os
dados relacionados ao instante de submissão de cada tarefa referentes ao primeiro período
posterior da carga de trabalho do item 1. Já no item 7, executamos esta carga do item 6 no
RGSA, com a CCC Proposta carregada com as configurações mais indicadas que foram
geradas na Fase de Predição no item 5. Sendo que essa execução do item 7 com o RGSA com
a CCC Proposta vai sendo reconfigurada dinamicamente entre as Y configurações do item 8 a
cada intervalo do período utilizado de acordo com os dados da CCC Proposta. Contudo,
precisamos alterar a forma de reconfiguração do RGSA para que a utilização da CCC
Proposta seja possível. O RGSA originalmente concebido tinha a reconfiguração realizada de
acordo com as anotações recebidas juntamente com as cargas ou sub-cargas de trabalho.
Assim, incorporamos no RGSA com a CCC Proposta, um mecanismo de alteração das
configurações da camada CCC Proposta para que as alterações sejam realizadas a cada
intervalo do período utilizado, de acordo com as informações que a CCC Proposta recebeu da
Fase de Predição das configurações.
Assim, queremos mostrar que a predição das configurações mais indicadas para cada
intervalo do período em questão utilizando agrupamento e modelagem estatística
fundamentada na execução anterior das cargas de trabalho é uma boa alternativa para auxiliar
nas tomadas de decisão do escalonador. Além disso, é uma maneira de implementar a CCC do
RGSA na prática de uma forma simples. Queremos mostrar, também, que a perda de
desempenho é a menor possível levando em consideração as características ideais que a CCC
do RGSA Original utiliza.
43
3.4 Considerações Finais
A nossa proposta de um controle de configuração para escalonadores reconfiguráveis
de tarefas paralelas apresentada para a CCC do RGSA utiliza predição das configurações
fundamentada no agrupamento e modelagem estatística das cargas de trabalho executadas no
passado para tomar as decisões. Este controle pode utilizar inúmeras variações para os
parâmetros como período e intervalos de tempo do período.
A nossa hipótese é que a CCC Proposta pode trazer ganhos de desempenho,
principalmente nos casos em que não sabemos que tipo de configurações o escalonador deve
possuir ou utilizar. Com a utilização de diversas configurações por meio de reconfigurações
feitas pelo algoritmo do RGSA a cada intervalo de tempo de um período, podemos ter ganhos
significativos. Isso, pois a predição das configurações do RGSA com a CCC Proposta é feita
com o intuito de utilizar as melhores configurações a cada intervalo do período. Além disso,
podemos introduzir novas opções de configuração no escalonador caso as configurações não
estejam atendendo às expectativas ou às características das cargas de trabalho.
44
4 RESULTADOS
Neste capítulo apresentam-se os resultados da pesquisa. Inicialmente apresentamos o
ambiente de experimentação, com as cargas de trabalho utilizadas, uma análise comparativa
destas cargas utilizadas na Fase de Predição, a configuração dos experimentos e os recursos
computacionais utilizados. Posteriormente apresentamos os resultados da Fase de Predição
das configurações, os resultados da Fase de Execução (operação) da carga, a análise dos
resultados e ao final, as considerações finais do capítulo.
4.1 Ambiente de Experimentação
Nesta pesquisa, sentimos a necessidade de utilizar cargas de trabalho reais para
verificação e validação do RGSA com a CCC Proposta visto que o RGSA não havia sido
testado, até o momento, com cargas reais. Queríamos que estas cargas possuíssem
características diferentes entre si, como descrito com mais detalhes no item 4.1.1. Com isso,
podemos testar o RGSA com a CCC Proposta em diferentes cenários. Assim, apesar de
utilizarmos simulação para testar a proposta de solução, queremos ficar mais próximos da
realidade com essa decisão de utilizar rastros de cargas reais executadas em sistemas de
computação paralelos reais.
Nos subitens desta seção 4.1, apresentamos inicialmente com maiores detalhes as
cargas de trabalho utilizadas, uma análise comparativa destas cargas utilizadas para
realizarmos o agrupamento e a modelagem estatística na Fase de Predição das configurações
do RGSA, a configuração dos experimentos e ao final os recursos computacionais utilizados
nas simulações.
4.1.1 Cargas de Trabalho
As cargas de trabalho que utilizamos nesta pesquisa foram obtidas de sistemas de
computação paralelos reais utilizados em produção e disponibilizadas no site
http://www.cs.huji.ac.il/labs/parallel/workload/logs.html (EXPERIMENTAL SYSTEMS
LAB, 2008). Estas cargas estão disponibilizadas em arquivos no formato .SWF (Standard
Workload Format) (THE STANDARD WORKLOAD FORMAT, 2011) os quais representam
45
logs brutos das tarefas executadas em sistemas de computação reais. Escolhemos três cargas
com características diferentes entre si para a pesquisa, que estão descritas a seguir:
a) The High Performance Computing Center North (HPC2N) Log – Log extraído do
Cluster Linux chamado Seth do High Performance Computing Center North na
Suécia. O rastro contém 527.371 tarefas executadas entre julho de 2002 e janeiro
de 2006. O Cluster Seth possui 120 nodos, cada um possuindo 2 processadores
modelo 240 AMD Athlon MP2000+ com freqüência de 1.667GHz e 1GB RAM. A
interconexão é feita por placas 3D SCI (Scalable Coherent Interface) organizadas
como grade 4x5x6 e utilizando também uma rede Fast Ethernet. O escalonador
utilizado é o Maui (MAUI CLUSTER SCHEDULER, 2011) e o desempenho total
chega a 800 Gflops. Deste rastro utilizamos o mês de Maio/2003 para a
modelagem estatística da carga de trabalho e a primeira semana de Junho/2003
para a execução dos testes de verificação;
b) The Los Alamos National Lab (LANL) CM-5 Log – Log extraído do cluster do
laboratório Los Alamos National Lab nos EUA (LOS ALAMOS NATIONAL
LAB, 2011), um sistema com 1024 nodos Connection Machine CM-5 com pelo
menos 32 processadores cada. O rastro contém 201.387 tarefas executadas entre
outubro 1994 e setembro de 1996. O escalonamento é realizado pelo software DJM
(Distributed Job Manager). Deste rastro utilizamos o mês de Setembro/1995 para
a modelagem estatística e a primeira semana de Outubro/1995 para a execução dos
testes de verificação;
c) The San Diego Supercomputer Center (SDSC) DataStar Log – Log extraído do
Cluster com 184 nodos IBM sendo 176 nodos p655 (com 8 processadores SMP
com freqüência de 1.5 GHz e 16GB RAM por nodo), e 8 nodos p690 (com 32
processadores SMP com freqüência de 1.7 GHz e 128 GB RAM ou 64 GB RAM
por nodo). Este Cluster é da Universidade da Califórnia em San Diego, EUA. O
co-escalonamento utilizado é o GUR (Grid Universal Remote). O rastro contém
96.089 tarefas executadas entre março de 2004 e março de 2005. Deste rastro
utilizamos o mês de Setembro/2004 para a modelagem estatística e a primeira
semana de Outubro/2004 para a execução dos testes de verificação.
Os arquivos obtidos no site citado estão no formato .SWF bruto como mostrado na
Figura 8. Cada linha do arquivo representa uma tarefa e suas características. Cada coluna
46
representa uma informação sobre a tarefa descrita em (THE STANDARD WORKLOAD
FORMAT, 2011). Foram utilizadas somente três colunas dos arquivos. Elas são a segunda, a
quarta e a quinta, conforme mostrado no exemplo a seguir, devido às características e
simplificações do simulador e da pesquisa. Estas três colunas representam, respectivamente,
tempo de submissão, tempo de execução e o número de processos.
Figura 8 - Parte do arquivo .SWF referente à carga HPC2N 1 0 308434 31405 30 31405 -1 30 37980 -1 1 1 1 -1 -1 1 -1 -1
2 8 308426 31039 30 31039 -1 30 37980 -1 1 1 1 -1 -1 1 -1 -1
3 12 308483 30978 30 30978 -1 30 37980 -1 1 1 1 -1 -1 1 -1 -1
4 179350 99808 143967 2 142977 -1 2 144000 -1 1 3 1 -1 -1 1 -1 -1
10 310085 29510 2326 40 2326 -1 40 43200 -1 1 4 1 -1 -1 1 -1 -1
11 342072 32 43306 32 43307 -1 32 43200 -1 1 4 1 -1 -1 1 -1 -1
12 342343 5 553 40 552.21 -1 40 43200 -1 1 4 1 -1 -1 1 -1 -1
13 342921 102 10027 40 10027 -1 40 43200 -1 1 4 1 -1 -1 1 -1 -1
14 347226 15 33156 8 33157 -1 8 86400 -1 1 5 1 -1 -1 1 -1 -1
15 347593 15 86462 8 86464 -1 8 86400 -1 1 5 1 -1 -1 1 -1 -1
Fonte: Adaptado de (THE STANDARD WORKLOAD FORMAT, 2 011)
Com as três colunas utilizadas dos arquivos no formato .SWF (segunda, quarta e
quinta colunas do arquivo original), criamos os arquivos no formato .LOG para serem
utilizados no ClusterSim. Num arquivo no formato .LOG, cada linha representa uma tarefa e
as colunas (separadas pelo caractere de tabulação) representam informações desta tarefa sendo
a primeira coluna o tempo de submissão, a segunda o tempo de execução da tarefa e a terceira
o número de processos da tarefa. Um exemplo de arquivo .LOG é mostrado na Figura 9.
Figura 9 - Parte do arquivo .LOG referente à carga HPC2N mostrada na Figura 8 0 31405 30
8 31039 30
12 30978 30
179350 143967 2
310085 2326 40
342072 43306 32
342343 553 40
342921 10027 40
347226 33156 8
347593 86462 8
Fonte: Adaptado de (THE STANDARD WORKLOAD FORMAT, 2 011)
O ClusterSim possui os modos de execução probabilístico e determinístico. O modo
probabilístico utiliza percentuais para representar uma carga com as respectivas tarefas e seus
47
processos baseado em um determinado intervalo ou período de tempo. Já no modo
determinístico, utilizamos os dados diretos de cada tarefa e seus respectivos processos, ou
seja, o rastro de uma determinada carga de trabalho.
Utilizando o modo probabilístico faremos a Fase de Predição das configurações da
carga utilizando agrupamento e modelagem estatística para gerar a CCC Proposta conforme
mostrado na Figura 10.
Figura 10 - Fluxo de geração da CCC Proposta na Fase de Predição (modo
probabilístico utilizando agrupamento e modelagem estatística) para carga de
Janeiro/2000
Fonte: Elaborado pelo autor
Na Figura 10, a partir da carga bruta do período de Janeiro/2000 mostrada no item 1, e
realizando o agrupamento e a modelagem estatística mostrados no item 2, geramos dados
sintéticos, utilizando a Técnica de Caracterização de Cargas de Trabalho (SANTOS; SILVA;
GÓES, 2009). Estes dados sintéticos são gerados no formato de arquivos workload (.WKL)
conforme mostrado anteriormente no exemplo da Figura 6. Para esta pesquisa, os arquivos
.WKL foram gerados a partir de arquivos .LOG contendo tarefas e processos de um mês
completo. Estes dados de um mês (N períodos) foram sintetizados com agrupamento em horas
de uma semana (intervalos do período) utilizando modelagem estatística para o cálculo das
médias aritméticas.
Assim, para a Fase de Predição utilizando modelagem estatística da carga de trabalho,
para gerarmos a CCC Proposta, configuramos o ClusterSim para o modo de execução
probabilístico utilizando estes arquivos .WKL gerados. Posteriormente, na Fase de Execução
mostrada na Figura 11, testamos a eficiência do RGSA com a CCC Proposta. Para isso,
configuramos o ClusterSim para o modo determinístico e executamos arquivos .LOG da
48
semana posterior aos dados utilizados para realizarmos a predição utilizando modelagem
estatística. Nesta Fase de Execução, conforme mostrado na Figura 11, a carga bruta do item 6
é executada no item 7 pelo RGSA com a CCC Proposta, onde a CCC Proposta vai
reconfigurando dinamicamente o RGSA com as configurações preditas na Fase de Predição.
As configurações disponíveis são mostradas no item 8.
Figura 11 - Fase de Execução (modo determinístico) para carga de Fevereiro/2000
Fase de Execução
Escolha das Configurações pelo
RGSA Proposto a cada hora
6.Carga Bruta
1a semana de
Fevereiro de 2000
8.Execução da
Carga Bruta 6 -
Configuração 12
...
7.Execução da
Carga Bruta 6 –
RGSA Proposto
8.Execução da
Carga Bruta 6 -
Configuração 1
Fonte: Elaborado pelo autor
Para fazermos a verificação do RGSA com a CCC Proposta, precisamos realizar testes
com as 12 configurações fixas conforme mostrado na Figura 12 utilizando dados da carga da
semana posterior aos dados (carga bruta do item 6 da Fase de Execução) utilizados para a
predição das configurações. Com isso podemos comparar o RGSA com a CCC Proposta com
relação às 12 diferentes opções de configuração disponíveis no RGSA, como mostrado no
Quadro 2.
49
Figura 12 - Estrutura de testes de verificação do RGSA com a CCC Proposta
Geração de Dados para
Comparação
Estrutura de testes de verificação
na Fase de Execução
9.Execução da
Carga Bruta 6 -
Configuração 1
9.Execução da
Carga Bruta 6 -
Configuração 12
...
Fonte: Elaborado pelo autor
4.1.2 Análise Comparativa das Cargas de Trabalho Utilizadas na Fase de Predição
A seguir, analisamos com detalhes as características das cargas de trabalho obtidas
com o agrupamento e a modelagem estatística que foram utilizadas na Fase de Predição das
configurações. A Tabela 1 a seguir nos mostra algumas informações referentes às cargas de
trabalho utilizadas nesta pesquisa. Os dados são referentes aos valores das médias aritméticas
extraídas das cargas por hora da semana. Devemos ressaltar que as cargas foram simuladas
considerando um cluster com 512 elementos de processamento. Este valor foi determinado
devido ao número máximo de processos por tarefa ser 512 de acordo com os logs das cargas
de trabalho utilizadas nesta pesquisa. E que o tempo de execução máximo por hora é 3.600
segundos para garantirmos que as tarefas se iniciam e terminam dentro da mesma hora e não
invadem a hora seguinte. Desta forma não atrapalhamos a predição das configurações
comprometendo o intervalo do período seguinte com tarefas do intervalo atual ou anterior.
Mas para conseguirmos isso, tivemos que partir as tarefas que invadiam horas diferentes e
colocar cada pedaço no intervalo (hora da semana) em que é executada.
50
Tabela 1 - Médias por hora referentes às características das cargas utilizadas na Fase de
Predição
Carga utilizada na
Predição (Amostra de
1 mês)
HH ( % )
HL ( % )
LL ( % )
LH ( % )
Num Jobs
Min Deg
Med Deg
Max Deg
Min Time (seg)
Med Time (seg)
Max Time (seg)
HPC2N 14,83 5,36 24,07 55,74 62 1 5 64 1 2.688 3.600 LANLCM5 21,75 17,90 31,48 28,87 14 32 124 512 1 1.659 3.600 SDSC 18,78 12,38 26,87 41,97 33 8 52 512 1 2.398 3.600
* Legenda: HH - alto nível de paralelismo - alto tempo de execução; HL - alto nível de paralelismo - baixo tempo de execução; LL - baixo nível de paralelismo - baixo tempo de execução; LH - baixo nível de paralelismo - alto tempo de execução; Num Jobs (Number of Jobs) - Número de tarefas submetidas; Min Deg (Minimum Degree) - Número mínimo de processos; Med Deg (Medium Degree) - Número médio de processos; Max Deg (Maximum Degree) - Número máximo de processos; Min Time (Minimum Time) - Tempo de execução mínimo; Med Time (Medium Time) - Tempo de execução médio; Max Time (Maximum Time) - Tempo de execução máximo.
Fonte: Dados da pesquisa
Primeiramente vamos explicar as colunas da tabela cujos dados foram gerados com
amostras de dados referentes a um mês. A primeira coluna é denominada “Carga utilizada na
Predição (Amostra de 1 mês)” e representa o nome da carga utilizada.
As quatro colunas seguintes dizem respeito às características das tarefas das cargas de
trabalho. Analisando a carga e utilizando a média, assim como em (SANTOS; SILVA;
GÓES, 2009), caracterizamos as cargas de acordo com duas características. Uma delas é a
quantidade de processos paralelos e a outra é o tempo de execução. Ambas podem ser
classificadas como H de high (alta) ou L de low (baixa). Assim, a segunda coluna, “HH (%)”,
diz respeito ao percentual de processos da carga com alto nível de paralelismo e com alto
tempo de execução. A terceira coluna, “HL (%)”, ao percentual de processos da carga com
alto nível de paralelismo e com baixo tempo de execução. A quarta coluna, “LL (%)”, ao
percentual de processos da carga com baixo nível de paralelismo e com baixo tempo de
execução. E a quinta coluna, “LH (%)”, ao percentual de processos da carga com baixo nível
de paralelismo e com alto tempo de execução.
As próximas quatro colunas mostram dados numéricos das tarefas das cargas. A sexta
coluna, “Num Jobs”, mostra-nos a média do número de tarefas submetidas por hora. A sétima,
“Min Deg”, mostra o número mínimo de processos que são enviados em uma hora. A oitava,
“Med Deg”, mostra o número médio de processos que são enviados em uma hora. A nona,
“Max Deg”, mostra o número máximo de processos que são enviados em uma hora.
51
Exemplificando os dados dessas quatro colunas, isso representa que em uma hora, para a
carga em questão, são enviadas tarefas com a quantidade numérica média de “Num Jobs”
sendo que cada tarefa pode ter entre “Min Deg” e “Max Deg” processos (com média de “Med
Deg” processos por tarefa da referida carga).
Por último, as três últimas colunas mostram dados referentes ao tempo de execução
das tarefas. A décima coluna, “Min Time”, representa o tempo de execução mínimo que uma
tarefa possui. A décima primeira coluna, “Med Time”, representa o tempo de execução médio
de cada tarefa da carga. E por fim, a décima segunda coluna, “Max Time”, representa o tempo
de execução máximo que uma tarefa da carga possui.
Comparando as três cargas mostradas na tabela Tabela 1, temos a HPC2N com os
menores valores para o mínimo (1), médio (5) e máximo (64) número de processos por hora,
tendo a média de tarefas submetidas por hora em 62. Apesar disso, 79,81% (LL + LH) das
tarefas submetidas tendem a ter de 1 a 5 processos, sendo estes com baixo nível de
paralelismo. Contudo, a carga possui a maior média de tempo de execução (2.688 segundos)
entre as três cargas.
Já a carga LANLCM5 tem a menor média de tarefas submetidas por hora (14) e a
menor média de tempo de execução (1.659 segundos) entre as três cargas. Contudo, 60,35%
(LL + LH) das tarefas submetidas tendem a ter de 32 a 124 processos com baixo nível de
paralelismo. Uma informação importante a ser ressaltada é que o número máximo de
processos é 512, exatamente o mesmo número de elementos de processamento que o cluster
utilizado nesta pesquisa possui.
Dentre as três cargas, a SDSC é a que demanda um tempo maior de processamento.
Apesar da quantidade média de tarefas submetidas por hora ser 33 e não ser a maior, 68,84%
(LL + LH) das tarefas tem de 8 a 52 processos e possuem processos com baixo nível de
paralelismo. E 41,97% (LH) das tarefas possuem o mesmo baixo nível de paralelismo e um
alto tempo de execução. Além disso, 60,75% (HH + LH) das tarefas possuem alto tempo de
execução.
Analisando as 3 cargas utilizadas nesta pesquisa para predição das configurações
utilizando agrupamento e modelagem estatística das cargas de trabalho executadas no
passado, podemos verificar, conforme detalhado acima, que as mesmas possuem
características diferentes entre si.
52
4.1.3 Configuração dos Experimentos
Baseado nos arquivos .LOG produzidos a partir dos rastros de execução de
computadores reais (arquivos .SWF), foram gerados os arquivos .WKL (workload). Cada
linha do arquivo .LOG representa uma tarefa com seus respectivos tempo de submissão,
tempo de execução e quantidade de processos. Com esses dados do .LOG de cada carga,
foram gerados arquivos .WKL sintetizados correspondentes aos dados de um mês, onde foram
geradas informações que representam a média de uma semana agrupada em horas. Assim,
cada linha do arquivo .WKL representa uma hora da semana começando no domingo às 0h.
Dessa forma, temos 168 linhas em cada arquivo .WKL, representando cada hora de uma
semana. As colunas representam os dados da média relativos a um mês sintetizadas em horas
de uma semana e representam informações como: grau de paralelismo (alto e baixo), tempo
de execução (alto e baixo), número de tarefas submetidas com seus respectivos números
mínimos, médios e máximos de processos submetidos e tempos de execução mínimos, médios
e máximos. Como temos 12 configurações diferentes para o algoritmo do RGSA, as quais
foram utilizadas nos experimentos nesta pesquisa, tivemos ao todo 2.016 (168 horas de uma
semana multiplicadas por 12 configurações diferentes) simulações para predição a serem
realizadas com cada carga de trabalho utilizada.
Para gerarmos o.WKL, utilizamos a Técnica de Caracterização de Cargas de Trabalho
de Supercomputadores descrita em (SANTOS; SILVA; GÓES, 2009). A técnica agrupa as
tarefas em intervalos de um período levando em conta os dados das cargas executadas em um
supercomputador em determinado conjunto de períodos como parâmetro para os
agrupamentos. Os parâmetros utilizados nesta pesquisa foram as horas da semana como sendo
os intervalos e uma semana como sendo o período. Nesta pesquisa o conjunto de períodos
utilizado é de um mês inteiro (N períodos de uma semana). Assim, com os parâmetros
utilizados nesta pesquisa, conseguimos caracterizar a carga de trabalho executada em um
determinado mês em um computador paralelo, com valores separados em horas de uma
semana.
Um dos problemas enfrentados foi a escolha da precisão do simulador na execução
dos experimentos, com o ClusterSim. O nível de precisão do simulador é baseado na
configuração do relógio virtual do ClusterSim. E cada variação na escala de precisão é
refletida no tempo gasto para realizar a etapa de predição das configurações. Como a precisão
impacta no tempo gasto, determinamos empiricamente um valor que tornava possível as
simulações com boa precisão e sem demorar muito tempo. Assim, utilizamos o valor de 100
53
segundos. Este foi um valor em que a Fase de Predição demandou um tempo considerável de
alguns meses para executarmos todos os testes necessários. Pelo fato de executarmos as
simulações da Fase de Predição das configurações utilizando agrupamento e modelagem
estatística em diversos computadores, conseguimos diminuir um pouco o tempo total gasto
nas simulações. Isso porque executamos as simulações em paralelo utilizando alguns
computadores.
O mesmo problema se aplica e foi enfrentado para a Fase de Execução, na qual
executamos arquivos .LOG com a carga bruta analítica do período posterior à carga utilizada
para a Fase de Predição. Contudo, o tempo gasto na execução do .LOG é menor que o tempo
gasto durante a Fase de Predição. Isso, pelo fato de não separarmos o período da carga
(semana) em intervalos (horas) e de executarmos esta carga sem aguardar a finalização de um
intervalo (hora) para iniciar a execução do próximo intervalo (próxima hora).
Para cada carga de trabalho utilizada, o primeiro passo foi realizar o agrupamento e a
modelagem estatística. Cada arquivo de carga utilizada refere-se ao agrupamento com a média
de tarefas executadas em uma semana. Cada semana possui 168 horas e a quantidade de
configurações disponíveis no RGSA com a CCC Proposta desta pesquisa é 12. Assim,
tivemos 2.016 execuções referentes a cada uma das 12 configurações existentes e a cada uma
das 168 horas da semana para realizar a modelagem estatística (12 configurações do RGSA
multiplicadas por 168 horas da semana). O segundo passo foi inserir esses dados em uma
matriz contendo as informações das execuções das 12 reconfigurações possíveis para o RGSA
para com isso, montarmos a CCC Proposta para o RGSA. Com esses dados, comparamos para
cada hora (intervalo) qual foi a melhor configuração do RGSA de acordo com o tempo de
execução gasto (obtido pelo valor da variável “simulationTime” no ClusterSim) e montamos a
CCC Proposta.
Após montarmos a CCC Proposta para o RGSA, executamos a carga de trabalho real
no ClusterSim com arquivos contendo o .LOG bruto de tarefas de máquinas reais do período
posterior (primeira semana subseqüente) à carga que a Fase de Predição foi realizada. Ao
final, executamos também o .LOG com as 12 diferentes configurações fixas montadas para o
ClusterSim para compararmos com os tempos de execução obtidos na execução do RGSA
com a CCC Proposta pelo valor da variável “simulationTime” do ClusterSim.
54
4.1.4 Recursos Computacionais
Esta pesquisa possui duas fases distintas: (i) Fase de Predição das configurações; e (ii)
Fase de Execução ou Fase de Operação. Estas fases das experimentações foram executadas
utilizando o simulador ClusterSim (GÓES; RAMOS; MARTINS, 2004) nos seguintes
computadores pessoais e nos desktops do PPGEE com as seguintes configurações agrupadas,
mostradas a seguir:
Notebooks:
a) 1 computador com processador Intel Core Duo 2GHz e 2GB memória RAM
b) 1 computador com processador Intel Core2 Duo 2GHz e 2GB memória RAM
c) 2 computadores com processador AMD Athlon 64 X2 1,6GHz e 2GB memória
RAM
Desktops:
d) 4 computadores com processador Intel Core2 Duo 1,8GHz e 1GB memória RAM
Conforme explicado anteriormente, o ClusterSim possui os modos de execução
probabilístico e determinístico. Para a Fase de Predição utilizando agrupamento e modelagem
estatística para montagem da CCC Proposta, configuramos o ClusterSim para o modo de
execução probabilístico utilizando arquivos .WKL caracterizados com a carga de períodos
(semanas) formando um mês. Posteriormente, na Fase de Execução, ou Fase de Operação,
utilizada para testar a eficiência do RGSA com a CCC Proposta, configuramos o ClusterSim
para o modo determinístico e executamos arquivos .LOG com as cargas reais de um período
(semana) posterior à predição realizada. Em todos os modos que configuramos no ClusterSim,
precisamos especificar algumas características do computador paralelo que iremos utilizar.
Assumimos que todos os processadores do computador paralelo que utilizamos para a
pesquisa são homogêneos e com freqüência de 1GHz e Ciclos por Instrução (CPI) igual a 1.
Com isso, mantemos o mesmo tempo de execução que as tarefas gastaram nos logs de cargas
extraídas, pois o ClusterSim converte cada segundo do log como 1 bilhão de instruções. Além
disso, o cluster que simulamos na pesquisa foi configurado no ClusterSim com 512 nodos
homogêneos, cada qual com 1 processador com as características citadas acima. Já o relógio
55
virtual do cluster é de 100 segundos de precisão. O ClusterSim possui outras configurações
que não são relevantes à pesquisa e que não serão citadas. Maiores detalhes podem ser
encontrados em (GÓES; RAMOS; MARTINS, 2004).
4.2 Fase de Predição
A Fase de Predição das configurações utilizando agrupamento e modelagem estatística
fundamentada na execução de cargas de trabalho do passado demandou alguns meses,
conforme detalhado anteriormente, devido aos recursos computacionais utilizados na
pesquisa. A Fase de Predição foi composta da execução das cargas de trabalho sintéticas com
cada uma das 12 configurações fixas disponíveis para configuração pelo RGSA com a CCC
Proposta e em cada uma das 168 horas da semana. Estas cargas sintéticas (arquivos .WKL),
foram gerados a partir de cargas de um mês utilizando a média aritmética para chegarmos ao
resultado de um período de uma semana. Com os dados dessas 12 execuções separadas por
horas de uma semana, conseguimos realizar a predição das configurações para a CCC
Proposta do RGSA, ou seja, conseguimos incorporar um preditor ou método de predição que
não dependa da geração das anotações das cargas na CCC Original do RGSA.
A seguir estão os gráficos mostrando as variações das 12 configurações do RGSA
durante as 168 horas de uma semana conforme os parâmetros utilizados nesta pesquisa
(período semanal dividido em intervalo de horas da semana). Os gráficos seguintes mostram a
melhor configuração fixa, dentre as disponíveis no RGSA, para cada uma das horas da
semana para as cargas de trabalho utilizadas na pesquisa.
56
Gráfico 1 - Preditor gerado para a Carga HPC2N
Fonte: Dados da pesquisa
Conforme mostrado no Gráfico 1, a carga HPC2N, não apresentou variação na
predição das melhores configurações, assim não apresentou reconfiguração do escalonador.
Para esta carga, apenas a Configuração 02 foi utilizada.
Durante a Fase de Predição para a carga HPC2N, os resultados dos tempos de
execução foram os mesmos para as Configurações 02, 04, 06, 08, 10 e 12 que apresentaram-se
como sendo as melhores. Se compararmos as Configurações 02, 04, 06, 08, 10 e 12, em todas,
apenas a configuração do esquema de desfragmentação se manteve inalterada. Isso mostra
que, para esta carga, as demais características (política de remoção da fila, esquema de
empacotamento e nível de multiprogramação) não influenciaram em nada no resultado. Daí o
mesmo resultado obtido por várias configurações. Assim, optamos por escolher a primeira das
melhores configurações encontradas para reduzirmos o impacto do tempo gasto para a
reconfiguração do algoritmo RGSA com a CCC Proposta.
57
Tabela 2 - Configurações utilizadas nos resultados da carga HPC2N - Fase de Predição
Configuração Quantidade Percentual Utilizado (%)
Configuração 01 0 0,00
Configuração 02 168 100,00
Configuração 03 0 0,00
Configuração 04 0 0,00
Configuração 05 0 0,00
Configuração 06 0 0,00
Configuração 07 0 0,00
Configuração 08 0 0,00
Configuração 09 0 0,00
Configuração 10 0 0,00
Configuração 11 0 0,00
Configuração 12 0 0,00 Fonte: Dados da pesquisa
A Tabela 2 mostrada acima apresenta os percentuais de utilização de cada uma das
configurações da CCC Proposta do RGSA para a carga HPC2N, na qual apenas a
Configuração 02 foi utilizada.
Gráfico 2 - Preditor gerado para a Carga LANLCM5
Fonte: Dados da pesquisa
Para a carga LANLCM5, podemos observar no Gráfico 2 que a configuração da CCC
Proposta do RGSA utilizou 7/12 das configurações e durante alguns horários seguidos da
58
semana foi constante. No geral não sofreu muitas reconfigurações e concentrou a maior parte
do tempo nas Configurações 02, 04, 06 e 08.
Tabela 3 - Configurações utilizadas nos resultados da carga LANLCM5 - Fase de
Predição
Configuração Quantidade Percentual Utilizado (%)
Configuração 01 4 2,38 Configuração 02 32 19,05 Configuração 03 1 0,60 Configuração 04 31 18,45 Configuração 05 0 0,00 Configuração 06 59 35,12 Configuração 07 0 0,00 Configuração 08 33 19,64 Configuração 09 0 0,00 Configuração 10 8 4,76 Configuração 11 0 0,00 Configuração 12 0 0,00
Fonte: Dados da pesquisa
A Tabela 3 mostrada acima apresenta os percentuais de utilização de cada uma das
configurações da CCC Proposta do RGSA para a carga LANLCM5, na qual 58,33% das
configurações disponíveis foram utilizadas.
59
Gráfico 3 - Preditor gerado para a Carga SDSC
Fonte: Dados da pesquisa
Já para a carga SDSC, observamos que a configuração da CCC Proposta do RGSA
utilizou 2/3 das configurações disponíveis e teve muitas reconfigurações conforme mostrado
no Gráfico 3. Porém, concentrou mais da metade do tempo na Configuração 06.
Tabela 4 - Configurações utilizadas nos resultados da carga SDSC - Fase de Predição
Configuraçãoo Quantidade Percentual Utilizado (%)
Configuração 01 3 1,79 Configuração 02 8 4,76 Configuração 03 5 2,98 Configuração 04 19 11,31 Configuração 05 0 0,00 Configuração 06 101 60,12 Configuração 07 0 0,00 Configuração 08 6 3,57 Configuração 09 3 1,79 Configuração 10 23 13,69 Configuração 11 0 0,00 Configuração 12 0 0,00
Fonte: Dados da pesquisa
60
A Tabela 4 mostrada acima apresenta os percentuais de utilização de cada uma das
configurações da CCC Proposta do RGSA para a carga SDSC, na qual 66,67% das
configurações disponíveis foram utilizadas.
Comparando a Fase de Predição para as 3 cargas de trabalho utilizadas, apenas uma
das cargas, a HPC2N, não sofreu nenhuma reconfiguração dentre as 168 reconfigurações que
as cargas poderiam realizar durante o período utilizado de uma semana. Já a carga LANLCM5
sofreu 47 reconfigurações e a SDSC 80 reconfigurações.
4.3 Fase de Execução (Operação)
Os resultados seguintes referem-se à Fase de Execução (ou Operação) do RGSA com
a CCC Proposta, que foi implementada no ClusterSim. Para este modo, utilizamos as 12
configurações fixas disponíveis no RGSA e o próprio RGSA utilizando a CCC Proposta.
Nesta fase, executamos as 3 cargas de trabalho que estão em formato de arquivo .LOG, as
quais são referentes ao período posterior ao utilizado na Fase de Predição. Ou seja, fizemos a
predição com cargas de um mês (N períodos) e montamos a CCC Proposta. Depois,
executamos as mesmas 3 cargas porém de períodos futuros (primeira semana do mês
seguinte) com o RGSA utilizando a CCC Proposta. Após isso, executamos estas mesmas
cargas futuras com as 12 configurações fixas do RGSA para comparações e análises.
4.3.1. Fase de Execução com a Carga HPC2N
Comparando-se a execução da carga HPC2N com as 12 configurações fixas utilizadas
pelo RGSA e o RGSA com a CCC Proposta, observa-se que o RGSA com a CCC Proposta
obteve o segundo melhor tempo de execução. A diferença absoluta entre os valores mínimo
(802.700 segundos) e máximo (1.001.300 segundos) foi de 198.600 segundos. O que
corresponde a 24,74% em relação ao mínimo e 19,83% em relação ao máximo, conforme
dados da Tabela 5.
61
Gráfico 4 - Tempo de execução para a carga HPC2N
Fonte: Dados da pesquisa
Neste caso específico da carga HPC2N, o RGSA com a CCC Proposta foi montado
utilizando-se apenas a Configuração 02 sem ter reconfiguração (ou seja, não se gastou tempo
com a reconfiguração do RGSA). Isso explica porque o RGSA com a CCC Proposta obteve o
mesmo tempo de execução da Configuração 02, visto que o RGSA com a CCC Proposta ficou
fixo nesta configuração.
Comparando as duas fases do RGSA com a CCC Proposta, percebemos que a Fase de
Predição das configurações gerou como resultado a Configuração 02 e a Fase de Execução
mostrou que a Configuração 05 foi a melhor. Isso mostra um erro da Fase de Predição do
RGSA. Já se compararmos os tempos de execução do RGSA com a CCC Proposta e o melhor
tempo dentre as configurações fixas, a perda de desempenho foi de 0,19% no tempo. E se
fizermos a mesma comparação do RGSA com a CCC Proposta com o pior tempo obtido,
tivemos um ganho de 24,51% com relação ao tempo de execução. Os valores podem ser
visualizados na Tabela 5 mostrada a seguir.
62
Tabela 5 - Tempo de execução HPC2N - RGSA com a CCC Proposta em relação às 12
configurações fixas
Configuração Tempo de Execução (s) Ganho RGSA com a CCC Proposta (%)
RGSA com a CCC Proposta 804.200 - Configuração 01 831.440 3,39 Configuração 02 804.200 0,00 Configuração 03 812.280 1,00 Configuração 04 804.200 0,00 Configuração 05 802.700 -0,19 Configuração 06 804.200 0,00 Configuração 07 1.001.300 24,51 Configuração 08 851.000 5,82 Configuração 09 1.001.300 24,51 Configuração 10 851.000 5,82 Configuração 11 1.001.300 24,51 Configuração 12 851.000 5,82
Fonte: Dados da pesquisa
Vale ressaltar que o cluster simulado na pesquisa (que possui 512 elementos de
processamento) foi pouco utilizado para a carga HPC2N, visto que a quantidade média de
tarefas disparadas foi de 62 e a quantidade máxima de processos disparados por tarefa por
hora foi de 64 conforme mostra a Tabela 1. Assim, não foi necessário ser reconfigurado pela
CCC Proposta do escalonador RGSA.
4.3.2. Fase de Execução com a Carga LANLCM5
Comparando as 12 configurações fixas e o RGSA com a CCC Proposta, o RGSA com
a CCC Proposta executando a carga LANLCM5 obteve o quinto melhor tempo de execução.
A diferença absoluta entre os valores mínimo (905.540 segundos) e máximo (1.095.760
segundos) foi de 190.220 segundos. O que corresponde a 21,01% em relação ao mínimo e
17,36% em relação ao máximo, conforme dados da Tabela 6.
63
Gráfico 5 - Tempo de execução para a carga LANLCM5
Fonte: Dados da pesquisa
Neste caso da carga LANLCM5, o RGSA com a CCC Proposta foi montado utilizando
7 das 12 configurações possíveis para o RGSA, utilizadas nesta pesquisa. Se comparados os
tempos do RGSA com a CCC Proposta e o melhor tempo, a perda foi de 4,04% no tempo. E
se compararmos o RGSA com a CCC Proposta e o pior tempo, tivemos um ganho de
desempenho de 16,11% com relação ao tempo de execução. Os ganhos podem ser
visualizados na Tabela 6 mostrada a seguir.
64
Tabela 6 - Tempo de execução LANLCM5 - RGSA com a CCC Proposta em relação às
12 configurações fixas
Configuração Tempo de Execução (s) Ganho RGSA com a CCC Proposta (%) RGSA com a CCC Proposta 943.700 - Configuração 01 1.044.740 10,71 Configuração 02 1.025.280 8,64 Configuração 03 964.060 2,16 Configuração 04 905.540 -4,04 Configuração 05 959.200 1,64 Configuração 06 939.400 -0,46 Configuração 07 1.095.760 16,11 Configuração 08 1.083.320 14,79 Configuração 09 927.300 -1,74 Configuração 10 919.500 -2,56 Configuração 11 1.031.980 9,35 Configuração 12 952.400 0,92
Fonte: Dados da pesquisa
4.3.3. Fase de Execução com a Carga SDSC
Comparando as 12 configurações fixas e o RGSA com a CCC Proposta, o RGSA com
a CCC Proposta executando a carga SDSC obteve o sétimo melhor tempo de execução. E
apesar disso, ele foi apenas 5,78% pior em termos de desempenho que o melhor caso. A
diferença absoluta entre os valores mínimo (1.403.300 segundos) e máximo (2.930.300
segundos) foi de 1.527.000 segundos. O que corresponde a 108,81% em relação ao mínimo e
52,11% em relação ao máximo, conforme dados da Tabela 7.
65
Gráfico 6 - Tempo de execução para a carga SDSC
Fonte: Dados da pesquisa
Neste caso da carga SDSC, o RGSA com a CCC Proposta foi montado utilizando 8
das 12 configurações possíveis para o RGSA, utilizadas nesta pesquisa. Se comparados os
tempos do RGSA com a CCC Proposta e o melhor tempo, a perda foi de 5,78% no tempo de
execução. E se compararmos o RGSA com a CCC Proposta com o pior tempo, obtivemos um
ganho de desempenho de 96,74% com relação ao tempo de execução. Os valores podem ser
visualizados na Tabela 7 mostrada a seguir.
66
Tabela 7 - Tempo de execução SDSC - RGSA com a CCC Proposta em relação às 12
configurações fixas
Configuração Tempo de Execução (s) Ganho RGSA com a CCC Proposta (%)
RGSA com a CCC Proposta 1.489.420 - Configuração 01 1.887.240 26,71 Configuração 02 2.000.740 34,33 Configuração 03 1.467.180 -1,49 Configuração 04 1.486.960 -0,17 Configuração 05 1.487.680 -0,12 Configuração 06 1.403.300 -5,78 Configuração 07 2.930.300 96,74 Configuração 08 2.042.180 37,11 Configuração 09 1.495.740 0,42 Configuração 10 1.484.840 -0,31 Configuração 11 1.633.120 9,65 Configuração 12 1.452.380 -2,49
Fonte: Dados da pesquisa
4.4 Análise dos Resultados
Após estes testes, onde analisamos a execução das 3 cargas de trabalho reais utilizadas
nesta pesquisa com as 12 configurações fixas disponíveis e com o RGSA com a CCC
Proposta, queríamos compará-lo com o melhor caso possível do RGSA com a CCC Proposta.
Ou seja, queríamos comparar os resultados obtidos nesta pesquisa com os resultados do
RGSA com a CCC Proposta Ideal ou Ótima (RGSA com a CCC Proposta que utiliza as
configurações ideais ou ótimas da CCC Proposta para cada hora da semana para a carga). Para
com isso mostrar a perda de desempenho do RGSA com a CCC Proposta em relação ao
RGSA com a CCC Proposta Ideal ou, simplesmente, RGSA Ideal.
O RGSA Ideal é a melhor configuração do RGSA com a CCC Proposta possível para
a carga utilizada. Porém, a dificuldade encontrada é que a resolução desse problema é um
problema com ordem de complexidade exponencial, conforme mostrado na Figura 13. Como
temos 12 configurações fixas de escalonamento diferentes que podem ser utilizados em cada
um dos 168 intervalos de hora do nosso período semanal, o RGSA Ideal tem como esforço 12
^ 168 combinações para se chegar ao resultado. Como as opções de configuração ou
escalonamento são muitas, decidimos utilizar uma aproximação que tivesse um esforço menor
para atingirmos o resultado.
Chamaremos de RGSA Aproximado o algoritmo montado que se baseará na execução
das tarefas disparadas por intervalo de hora. Utilizaremos as mesmas cargas de trabalho da
67
Fase de Execução do RGSA com a CCC Proposta. Primeiramente, executamos cada carga de
trabalho citada com as 12 configurações fixas disponíveis no RGSA com a CCC Proposta e
extraímos os resultados. Após isso, separamos as tarefas dessa carga por hora da semana em
que foram disparadas e por configuração fixa utilizada. De posse das informações das tarefas
separadas por hora da semana e por configuração fixa, escolhemos como a melhor
configuração para determinada hora da semana aquela em que todas as tarefas disparadas
nessa mesma hora finalizarem primeiro. Ao final, montamos a CCC utilizando estas
configurações extraídas para cada hora da semana e executamos a carga de trabalho com o
RGSA Aproximado. Para tal, o esforço será da multiplicação de 12 (número de opções de
configurações fixas diferentes) por 168 (quantidade de intervalos de hora da semana). Isso,
pois com apenas uma execução da carga de trabalho para cada uma das 12 configurações fixas
de escalonamento conseguiremos chegar ao resultado da aproximação desejada.
Figura 13 - Comparação de esforço para calcular RGSA Ideal e Aproximado
RGSA Ideal: esforço de 12 ^ 168
RGSA Aproximado: esforço de 12 x 168
Considerando que 10 x 12 x 168 ~= 12 ^ 4, ou seja, 20.160 ~= 20.736 então:
12 ^ 168 ~= 12 ^ 164 x 12 ^ 4
12 ^ 168 ~= 12 ^ 164 x 10 x 12 x 168
Esforço RGSA Ideal ~= 10 x 12 ^ 164 vezes maior que o RGSA Aproximado
Fonte: Elaborada pelo autor
Nosso principal problema foi que as tarefas disparadas em uma determinada hora não
terminam necessariamente na mesma hora. Na Fase de Predição isso acontece porque
dividimos as tarefas em partes de no máximo 1 hora (3.600 segundos) cada e garantimos que
todas as tarefas se iniciam no início de cada hora. Com isso as tarefas não invadem outras
horas. Já na Fase de Execução utilizando as cargas reais, as tarefas iniciam-se em tempos
diferentes. Além disso, podem iniciar em uma determinada hora e terminar em outra hora
subseqüente. Isto acarreta em atraso na execução dos processos das tarefas. Desde modo, o
tempo de execução total da carga referente a 1 semana completa na simulação pode ser
superior a 1 semana (60 segundos x 60 minutos x 24 horas x 7 dias = 604.800 segundos).
Assim, quando definimos que uma configuração é melhor em determinada hora, não
podemos garantir que ela é realmente a melhor baseando-se nessa heurística ou aproximação.
Pois se houverem processos de outras horas sendo executados simultaneamente, não podemos
68
garantir que as configurações que estiverem ativas na CCC do RGSA naquele momento são
as melhores. Essa foi a aproximação utilizada, uma heurística de aproximação das melhores
configurações para cada intervalo de hora do período de uma semana com um esforço 10 x 12
^ 164 vezes menor que o do RGSA Ideal. E essa aproximação demonstrou ser melhor que o
RGSA utilizando a CCC Proposta em 1 das 3 cargas de trabalho reais utilizadas. A seguir
apresentamos os resultados da comparação entre os tempos de execução utilizando as
configurações de escalonamento fixas, o RGSA com a CCC Proposta e o RGSA Aproximado.
Gráfico 7 - Comparativo dos tempos de execução para a carga HPC2N (melhor tempo,
pior tempo, RGSA com a CCC Proposta e RGSA Aproximado)
Fonte: Dados da pesquisa
O Gráfico 7 acima mostra os principais tempos de execução para a carga HPC2N. O
melhor tempo foi utilizando a Configuração 05, o pior tempo foi quando o escalonador
utilizou a Configuração 07. O RGSA com a CCC Proposta teve seu tempo de execução 0,19%
pior que o da melhor configuração (Configuração 05). Além disso, o RGSA com a CCC
Proposta não utilizou reconfiguração (utilizou apenas a Configuração 02). Já o RGSA
Aproximado foi 5,7% pior em termos de desempenho (tempo de execução) do que o RGSA
com a CCC Proposta.
69
Gráfico 8 - Comparativo dos tempos de execução para a carga LANLCM5 (melhor
tempo, pior tempo, RGSA com a CCC Proposta e RGSA Aproximado)
Fonte: Dados da pesquisa
Para a carga LANLCM5, o Gráfico 8 acima nos mostra os principais tempos de
execução que iremos comparar. O melhor tempo foi utilizando a Configuração 04 e o pior
tempo foi quando o escalonador utilizou a Configuração 07. Assim como aconteceu para a
carga HPC2N mostrada anteriormente, a aproximação utilizada para o RGSA Aproximado foi
pior em termos de desempenho (tempo de execução) do que o RGSA com a CCC Proposta. O
percentual neste caso foi 3,84% pior.
70
Gráfico 9 - Comparativo dos tempos de execução para a carga SDSC (melhor tempo,
pior tempo, RGSA com a CCC Proposta e RGSA Aproximado)
Fonte: Dados da pesquisa
Já o Gráfico 9 acima mostra os principais tempos de execução para a carga SDSC. O
melhor tempo foi utilizando a Configuração 06 e o pior tempo foi quando o escalonador
utilizou a Configuração 07. Para esta carga de trabalho, a aproximação utilizada para o RGSA
Aproximado foi 2,62% melhor em termos de desempenho (tempo de execução) do que o
RGSA com a CCC Proposta.
Conforme os tempos de execução mostrados nos 3 primeiros gráficos desta seção 4.4;
Gráfico 7, Gráfico 8 e Gráfico 9; a Configuração 07 obteve o pior tempo de execução para as
3 cargas de trabalho. E o RGSA Aproximado obteve sucesso em 1 das 3 cargas de trabalho
utilizadas.
O esperado era que o RGSA com a CCC Proposta tivesse os melhores resultados em
comparação com as configurações fixas. Mas algumas simplificações utilizadas na pesquisa
podem explicar esse fato e citamos 3 como as principais. O erro ou qualidade da
caracterização da carga de trabalho utilizada na Fase de Predição é uma das simplificações
utilizadas, a qual gera um erro na própria predição que irá se propagar na Fase de Execução.
O intervalo em horas utilizado é outra simplificação que afeta. Ou seja, os parâmetros
utilizados para período e intervalo podem ter impactado diretamente nos resultados. Assim,
um intervalo menor, de 30 minutos ou 15 minutos, por exemplo, deve ser investigado
futuramente para uma melhor compreensão do impacto desse parâmetro. Por último, a
simplificação do RGSA com a CCC Proposta em relação ao RGSA com a CCC Proposta
71
Ideal (que utiliza as melhores configurações e que é um problema com ordem de
complexidade exponencial).
Assim, essas 3 simplificações citadas podem ter seus erros de precisão multiplicados e
podem ter gerado os resultados apresentados na pesquisa. Um exemplo claro disso foram os
resultados encontrados para a carga HPC2N. Na Fase de Predição, a Configuração 02 foi a
melhor configuração encontrada e na Fase de Execução foi mostrado que a Configuração 05
foi a melhor. Apesar de não conseguirmos comprovar essa hipótese, conseguimos mostrar que
ela foi bem próxima dos melhores casos, nunca se mostrando o pior caso.
Nos nossos exemplos de cargas de trabalho, se tivéssemos escolhido aleatoriamente e
sem nenhum critério uma determinada configuração fixa, e esta configuração fosse a pior para
a carga de trabalho, teríamos uma perda de até 16,11 % no melhor caso e uma perda de
96,74% no pior caso, se comparado com o RGSA com a CCC Proposta. E caso
escolhêssemos a melhor configuração fixa aleatoriamente e sem nenhum critério, podíamos
ter obtido um ganho de 0,19% no melhor caso e um ganho de 6,14% no pior caso, se
comparado ao RGSA com a CCC Proposta. Com isso, o que queríamos mostrar é que a
predição das configurações utilizando agrupamento e modelagem estatística fundamentada na
execução de cargas de trabalho do passado é bastante útil. Principalmente quando não
sabemos à priori as características da carga de trabalho a serem executadas ou quando não
dispomos de tempo suficiente para analisá-las imediatamente antes de executá-las.
72
Tabela 8 - Dados comparativos das cargas de trabalho contendo as médias das
características por hora utilizadas na Predição, obtidas com modelagem estatística, e
Execução
Carga utilizada na
Predição (Amostra de
1 mês)
HH ( % )
HL ( % )
LL ( % )
LH ( % )
Num Jobs
Min Deg
Med Deg
Max Deg
Min Time (seg)
Med Time (seg)
Max Time (seg)
HPC2N 14,83 5,36 24,07 55,74 62 1 5 64 1 2.688 3.600 LANLCM5 21,75 17,90 31,48 28,87 14 32 124 512 1 1.659 3.600 SDSC 18,78 12,38 26,87 41,97 33 8 52 512 1 2.398 3.600
Carga
utilizada na Execução
(Amostra de 1 semana)
HH ( % )
HL ( % )
LL ( % )
LH ( % )
Num Jobs
Min Deg
Med Deg
Max Deg
Min Time (seg)
Med Time (seg)
Max Time (seg)
HPC2N 8,75 9,22 43,03 39,00 71 1 5 66 1 1.758 3.600 LANLCM5 11,76 13,59 47,61 27,04 13 32 156 512 2 1.250 3.600 SDSC 11,60 12,60 29,95 45,85 43 8 41 512 2 2.305 3.600
* Legenda: HH - alto nível de paralelismo - alto tempo de execução; HL - alto nível de paralelismo - baixo tempo de execução; LL - baixo nível de paralelismo - baixo tempo de execução; LH - baixo nível de paralelismo - alto tempo de execução; Num Jobs (Number of Jobs) - Número de tarefas submetidas; Min Deg (Minimum Degree) - Número mínimo de processos; Med Deg (Medium Degree) - Número médio de processos; Max Deg (Maximum Degree) - Número máximo de processos; Min Time (Minimum Time) - Tempo de execução mínimo; Med Time (Medium Time) - Tempo de execução médio; Max Time (Maximum Time) - Tempo de execução máximo. Fonte: Dados da pesquisa
A Tabela 8 acima mostra os dados comparativos entre as cargas utilizadas para a Fase
de Predição e para a Fase de Execução (ou Fase de Operação). Os dados são referentes às
médias de uma hora típica da semana calculada a partir da média da amostra utilizada. O
primeiro item a se analisar é sobre os tamanhos das amostras utilizadas. Para a Fase de
Predição (1ª parte da Tabela 8), utilizamos 1 mês de carga (ou N períodos de uma semana). Já
para a Fase de Execução da carga (2ª parte da Tabela 8), utilizamos 1 período, que é uma
semana. Os dados mostrados para as cargas utilizadas na Fase de Predição foram obtidos à
partir de agrupamento e modelagem estatística e calculados utilizando dados de um mês
inteiro como amostra. Para as cargas utilizadas na Fase de Execução (2ª parte da Tabela 8), os
dados foram gerados utilizando a primeira semana do mês subseqüente à carga utilizada para
a Fase de Predição como amostra. E é nesta Fase de Execução que testamos e verificamos o
RGSA com a CCC Proposta nesta pesquisa.
73
Analisando os dados da Tabela 8, podemos verificar que a carga SDSC possui as
características mais similares, considerando-se todas as colunas, e com menor variação entre a
utilizada para a Fase de Predição e a utilizada para a Fase de Execução.
Na Tabela 9 mostramos a comparação do RGSA com a CCC Proposta com relação às
12 configurações fixas para as cargas de trabalho utilizadas nesta pesquisa. Na coluna “RGSA
Melhor” é mostrado a quantidade de vezes que o RGSA com a CCC Proposta foi melhor
comparando com as 12 configurações fixas. A coluna “RGSA Igual”, por sua vez, mostra a
quantidade de vezes que o RGSA com a CCC Proposta foi igual à alguma das 12
configurações fixas. E a coluna “RGSA Pior”, a quantidade de vezes que o RGSA com a CCC
Proposta foi pior. Por fim, as duas últimas colunas, “Melhor Caso” e “Pior Caso”, mostram o
percentual de desempenho que o RGSA com a CCC Proposta obteve em relação à melhor e à
pior configuração fixa, respectivamente.
Tabela 9 - Comparação entre as configurações fixas e o RGSA com a CCC Proposta
para as cargas
Carga de Trabalho
RGSA com a CCC Proposta x Configurações Fixas Desempenho RGSA
RGSA Melhor RGSA Igual RGSA Pior Melhor Caso Pior Caso
HPC2N 8 3 1 24,51% -0,19%
LANLCM5 8 0 4 16,11% -4,04%
SDSC 6 0 6 96,74% -5,78% Fonte: Dados da pesquisa
Conforme mostrado na Tabela 8, a carga HPC2N utilizada na Fase de Predição possui
20,19% de tarefas com alto nível de paralelismo (HH + HL) e 79,81% com baixo nível de
paralelismo (LL + LH). Já a carga HPC2N utilizada na Fase de Execução possui 17,97% de
tarefas com alto nível de paralelismo (HH + HL) e 82,03% com baixo nível de paralelismo
(LL + LH). Porém, a diferença maior se dá no tempo médio de execução dos processos. Na
carga utilizada na Fase de Predição, esse tempo é de 2.688 segundos e na carga utilizada na
Fase de Execução, 1.758 segundos. Contudo, a carga HPC2N não sofreu muito impacto com
as alterações das configurações. Isso, porque a quantidade máxima de processos por tarefa
disparada foi de 64 para a carga utilizada na Fase de Predição e 66 para a utilizada na Fase de
Execução. E a quantidade de elementos de processamento (EP) no cluster simulado foi de
512. Como mostrado na Tabela 9, a variação de ganho do RGSA com a CCC Proposta foi de -
0,19% no pior caso e de 24,51% no melhor caso em relação ao desempenho. E em apenas
74
uma opção de configuração o RGSA com a CCC Proposta foi pior (8,33% das vezes) e nas
demais (91,67%), seu desempenho foi igual ou melhor que o das configurações fixas.
Para LANLCM5, a Tabela 8 mostra que a carga utilizada na Fase de Predição possui
39,65% das tarefas com alto nível de paralelismo (HH + HL) e 60,35% com baixo nível de
paralelismo (LL + LH). Já para a carga utilizada na Fase de Execução, 25,35% das tarefas
possuem alto nível de paralelismo (HH + HL) e 74,65% baixo nível de paralelismo (LL +
LH), o que mostra uma diferença considerável. Realizamos a Fase de Predição com
configurações propícias para uma carga com aproximadamente 40% de tarefas com alto nível
de paralelismo e 60% com baixo nível de paralelismo e após a predição das configurações, a
Fase de Execução foi executada com uma carga com 25% e 75%, respectivamente. Existem
também, diferenças consideráveis entre as cargas utilizadas na predição das configurações e
na Fase de Execução com relação à quantidade média de processos por tarefas disparadas e no
tempo médio de execução dos processos. Na carga utilizada na Fase de Predição, a quantidade
média de processos por tarefa foi de 124 e o tempo médio de execução dos mesmos foi de
1.659 segundos. E na carga utilizada na Fase de Execução a quantidade média foi de 156 e o
tempo médio 1.250 segundos. Apesar de o tempo médio ter diminuído na Fase de Execução, a
quantidade média de processos aumentou. E essas variações aconteceram em proporções
iguais, aumentando em 25,81% para a quantidade média de processos e diminuindo em
24,65% para o tempo médio de execução da carga utilizada na Fase de Predição com relação à
carga utilizada na Fase de Execução. Como mostrado na Tabela 9, a variação de ganho de
desempenho do RGSA com a CCC Proposta foi de -4,04% no pior caso e de 16,11% no
melhor caso. E em 2/3 das vezes (66,67%) o RGSA com a CCC Proposto foi melhor que as
configurações fixas.
Na carga SDSC, de acordo com a Tabela 8, a carga utilizada na Fase de Predição
possui 31,16% de tarefas com alto nível de paralelismo (HH + HL) e 68,84% de tarefas com
baixo nível de paralelismo (LL + LH). Já para a carga utilizada na Fase de Execução, 24,20%
das tarefas possuem alto nível de paralelismo (HH + HL) e 75,80% possuem baixo nível de
paralelismo (LL + LH). Isso mostra uma diferença considerável na divisão da carga utilizada
para Fase de Predição das configurações (1/3 com alto nível de paralelismo e 2/3 com baixo
nível de paralelismo) e na Fase de Execução (1/4 com alto nível de paralelismo e 3/4 com
baixo nível de paralelismo). Contudo, a diferença mais considerável se deu na coluna HH e
foi 38,23% menor da carga utilizada para predição das configurações com relação à carga
utilizada na Fase de Execução. Outras diferenças entre as cargas utilizadas nas Fases de
Predição e Execução foram na quantidade média de tarefas por hora (33 na de Predição e 43
75
na de Execução) e quantidade média de processos por tarefas disparadas (52 na de Predição e
41 na de Execução). Essa variação foi 30,30% maior na quantidade média de tarefas,
enquanto a quantidade média de processos por tarefa disparada foi de 21,15% menor, se
comparados a Fase de Predição em relação à Fase de Execução. Os ganhos para essa carga
foram consideráveis e os dados da Tabela 9 mostram a variação do RGSA com a CCC
Proposta de -5,78% no pior caso e de 96,74% no melhor caso. O RGSA com a CCC Proposta
foi melhor em 50% das vezes e nas outras 50% das vezes em que foi pior, o RGSA com a
CCC Proposta teve uma perda máxima de 5,78% no desempenho.
Tabela 10 - Tempo médio de execução das cargas de trabalho com as 12 configurações
fixas comparados ao RGSA com a CCC Proposta utilizadas na execução
Carga Tempo médio execução das
12 configurações fixas
Tempo RGSA com a CCC
Proposta
Desempenho RGSA com a CCC Proposta
HPC2N 867.993 804.200 7,93%
LANLCM5 987.373 943.700 4,63%
SDSC 1.730.972 1.489.420 16,22% Fonte: Dados da pesquisa
Outra comparação a se fazer é a do RGSA com a CCC Proposta com o tempo médio
de execução das 12 configurações fixas. Se considerarmos os tempos médios das 12
configurações fixas utilizadas na Fase de Execução e compararmos com os tempos do RGSA
com a CCC Proposta para as 3 cargas de trabalho utilizadas, percebemos que o RGSA com a
CCC Proposta foi melhor. Conforme mostrado na Tabela 10, a eficiência média do RGSA
com a CCC Proposta foi considerável e mostra que essa técnica é uma boa escolha como
controle de escalonamento reconfigurável de tarefas paralelas e que merece um estudo maior
em outras pesquisas.
4.5 Considerações Finais
Os resultados de verificação do RGSA utilizando a CCC Proposta foram realizados
somente com uma combinação de parâmetros de regularidade temporal. Os parâmetros desta
pesquisa são: (i) período; (ii) intervalo do período; e (iii) quantidade de períodos para
agrupamento e modelagem estatística da carga de trabalho e para a predição de configuração.
Esta combinação utilizou um período semanal, subdividido em intervalos de horas e
fundamentada na média das semanas do mês anterior (N períodos) à carga executada. O que
76
devemos deixar claro é que essa nossa hipótese de solução permite que utilizemos várias
outras combinações de parâmetros diferentes da utilizada neste trabalho.
Outro fator relevante que podemos ressaltar é que obtivemos resultados diferentes para
as cargas de trabalho utilizadas. O que podemos salientar é que a heterogeneidade ou a
homogeneidade do comportamento temporal das cargas em alguns momentos utilizados na
Fase de Predição das configurações utilizando agrupamento e modelagem estatística das
cargas de trabalho e fundamentada nas execuções destas cargas no passado pode ter
impactado diretamente em alguns resultados obtidos. E que provavelmente com outras
combinações de parâmetros podemos obter melhores resultados. E isso deve ser analisado
melhor futuramente em outros trabalhos.
77
5 CONCLUSÃO
Neste capítulo apresenta-se a conclusão da pesquisa onde são discutidos os resultados
da pesquisa, apresentadas as principais contribuições e indicados alguns dos possíveis
trabalhos futuros.
5.1 Discussão dos Resultados
Com relação aos testes, resultados e parâmetros de temporalidade utilizados nesta
pesquisa os nossos objetivos foram alcançados. Nos testes obtivemos resultados diferentes
para as cargas de trabalho devido à heterogeneidade das mesmas. Contudo, um estudo melhor
será realizado em trabalhos futuros para que os impactos dos diferentes parâmetros de
temporalidade possam ser analisados com mais detalhes. Entre os parâmetros estão o período,
os intervalos do período e a quantidade de períodos utilizados para a realização do
agrupamento e a modelagem estatística das cargas de trabalho. Isso porque para algumas
cargas foram observados ganhos maiores e para outras cargas, ganhos menores com relação
aos tempos de execução durante a Fase de Execução das cargas.
Porém, vale ressaltar o fato da nossa solução ter se mostrado sempre próxima das
melhores configurações fixas disponíveis no RGSA com pequenas perdas em relação aos
tempos de execução. Isso não tira o mérito do trabalho e mostra que a solução, além de
promissora, é viável e merece ser estudada com maior profundidade em trabalhos futuros.
É importante mostrar que esse novo controle de configuração que utiliza predição das
configurações fundamentada no agrupamento e na modelagem estatística das cargas de
trabalho executadas no passado trouxe ganhos médios em todas as comparações com as
configurações fixas, disponíveis no RGSA. Também, nos casos em que uma escolha aleatória
e sem critério de configuração acontecer, isso pode gerar uma perda de desempenho grande se
comparada com as demais configurações fixas disponíveis no RGSA. Assim, o RGSA
utilizando o novo controle de configuração incorporado na CCC obteve ganhos tanto em
comparação à média das 12 configurações fixas disponíveis no RGSA quanto a algumas das
configurações fixas comparadas isoladamente. E comparando o RGSA com a CCC Proposta e
as configurações fixas que se mostraram melhores que o mesmo, o desempenho foi, no pior
dos casos, 5,78% pior.
78
Assim, com relação à nossa proposta de CCC, os nossos objetivos foram alcançados
completamente. A CCC Proposta mostrou-se viável em relação à implementação e utilização
em sistemas de computação paralelos reais.
Os resultados alcançados nesta pesquisa se mostraram de acordo com os esperados em
nossos objetivos. O novo controle de configuração para escalonadores reconfiguráveis de
tarefas paralelas utilizando predição das configurações baseada na temporalidade das cargas
de trabalho executadas no passado foi implementado na CCC Proposta do RGSA. Este novo
controle se mostrou um meio interessante e promissor, além de produzir bons resultados. Os
mesmos foram satisfatórios e sempre próximos do melhor resultado para todas as cargas de
trabalho utilizadas nesta pesquisa.
A comparação do RGSA com a CCC Proposta com o RGSA com a CCC Proposta
utilizando as configurações ideais ou ótimas foi realizada utilizando a heurística de
aproximação que descrevemos nesta pesquisa para o RGSA Aproximado. O RGSA
Aproximado foi melhor que o RGSA com a CCC Proposta para 1 das cargas de trabalho.
Assim, essa heurística deve ser melhorada com o estudo de uma forma melhor de
aproximação do RGSA com a CCC Proposta contendo as configurações ótimas.
5.2 Principais Contribuições
A principal contribuição deste trabalho é a apresentação de um novo controle de
configuração para escalonadores reconfiguráveis de tarefas paralelas que utiliza a predição
das configurações baseada na regularidade temporal das cargas de trabalho executadas no
passado. Este controle foi implementado na Camada de Controle de Configuração (CCC) do
RGSA, que chamamos de CCC Proposta. Este novo controle é uma evolução da CCC do
RGSA Original, a qual realiza a reconfiguração do escalonador baseado na anotação das
cargas que são enviadas juntamente com a própria carga no momento de submissão. O RGSA
com a CCC Proposta está mais próximo da realidade com a inclusão do novo controle de
configuração proposto nesta pesquisa. O RGSA com a CCC Proposta não necessita da
anotação das cargas de trabalho para escolher a configuração que o escalonador irá utilizar.
Ele, utilizando este novo controle de configuração, usa a predição fundamentada em
agrupamento e modelagem estatística da carga de trabalho para predizer as configurações
baseando-se nas execuções de cargas passadas para as tomadas de decisão.
79
5.3 Trabalhos Futuros
Entre os possíveis trabalhos futuros, podemos citar a investigação de outros conjuntos
de parâmetros de temporalidade na proposta do controle de configuração que foi utilizada na
CCC Proposta. Entre estes conjuntos de parâmetros, destacamos a variação dos intervalos de
período utilizados nesta pesquisa. Podemos, ao invés de utilizar as horas de uma semana,
utilizar intervalos menores como minutos, ou maiores como turnos (manhã, tarde, noite).
Como outro trabalho futuro, podemos utilizar outras técnicas de caracterização de
cargas de trabalho e compará-las com a técnica utilizada nesta pesquisa.
Outro trabalho futuro está no teste e verificação da predição das configurações ao
longo de vários períodos seguidos. Ou seja, a Fase de Predição de períodos adjacentes futuros
utilizando N períodos anteriores funcionando como uma janela deslizante, se deslocando à
medida que os períodos forem chegando. Com isso, teremos que automatizar a realização da
Fase de Predição das configurações para as cargas de trabalho futuras, para que seja realizada
durante a Fase de Execução de cargas atuais. Assim, a CCC Proposta utilizará as
configurações preditas com cargas de trabalho mais recentes possíveis.
Pretendemos investigar a heurística de aproximação que utilizamos para extrair os
resultados do RGSA Aproximado, pois precisa ser melhorada. E, também, analisar as razões
da Configuração 07 ter sido a pior configuração para todas as cargas de trabalho utilizadas
nesta pesquisa.
A utilização e experimentação da CCC Proposta do RGSA em um ambiente real não
simulado é um outro trabalho futuro para mostrar que este novo controle de configuração
pode ser interessante e mostrar bons resultados na prática.
Uma análise da utilização e ocupação do computador paralelo por intervalo de tempo
precisa ser realizada para sabermos o impacto da quantidade de EPs utilizados e não
utilizados nestes tempos.
Precisamos também, melhorar e automatizar algumas funcionalidades no simulador
ClusterSim para agilizar a análise das cargas de trabalho executadas de acordo com as
configurações utilizadas no computador paralelo configurado no simulador. Também é
interessante reduzirmos os tempos com simulação para que possam ser realizadas mais
operações no mesmo espaço de tempo, com o intuito de melhorar as análises nos estudos.
O uso do RGSA em outras plataformas de computação paralela como, por exemplo,
no contexto de Cloud Computing, é um outro trabalho futuro.
80
Por fim, citamos o estudo para que seja utilizado este novo controle de configuração
fundamentado na predição das configurações baseada na regularidade temporal das cargas de
trabalho executadas no passado em outros escalonadores configuráveis ou reconfiguráveis de
tarefas paralelas diferentes do RGSA Original (GÓES; MARTINS, 2004a).
81
REFERÊNCIAS
ALMASI, George S.; GOTTLIEB, Allan. Highly parallel computing, 2nd ed. Redwood City: Benjamin-Cummings Publishing Company, 1994. BATAT, Anat; FEITELSON, Dror G. Gang scheduling with memory considerations. In IEEE INTERNATIONAL PARALLEL AND DISTRIBUTED PROCESSING SYMPOSIUM, 14, 2000, Cancun. Proceedings. p. 109-114. BUYYA, Rajkumar. High performance cluster computing: architectures and systems, 1st ed. New Jersey: Prentice Hall, 1999, v. 1. CAMPOS, Luis M., Resource management techniques for multiprogrammed distributed systems. 1999. 131f. Tese (Doutorado) - University of California, Irvine. CLEMENTE, Juan A. et al. A hardware task-graph scheduler for reconfigurable multi-tasking systems. In RECONFIG - INTERNATIONAL CONFERENCE ON RECONFIGURABLE COMPUTING AND FPGAS, 08, 2008, Cancun. Paper, p. 79-84. EL-REWINI, Hesham; ALI, Hesham H.; LEWIS, Ted. Task scheduling in multiprocessing systems. IEEE COMPUTER , v. 28, n. 12, p. 27-37, Dec. 1995. EXPERIMENTAL SYSTEMS LAB. The Hebrew University – Experimental Systems Lab. Laboratório da universidade Hebrew University of Jerusalem, Israel. Disponível em <http://www.cs.huji.ac.il/labs/parallel/> Acesso em: 19 dez. 2008.
FEITELSON, Dror G. A survey of scheduling in multiprogrammed parallel systems. Yorktown Heights: IBM T. J. WATSON RESEARCH CENTER, 1997. Research Report RC 19790 (87657). FLYNN, Michael J. Very high-speed computing systems. Proceedings of the IEEE, v. 54, n. 12, p. 1901-1909, Dec. 1966. FLYNN, Michael J. Some computer organizations and their effectiveness. IEEE Transactions on Computers, v. c-21, n. 9, p. 948-960, Sep. 1972. FRACHTENBERG, Eitan; SCHWIEGELSHOHN, Uwe. New challenges of parallel job scheduling. In: INTERNATIONAL CONFERENCE ON JOB SCHEDULING STRATEGIES FOR PARALLEL PROCESSING, 13, 2007, Seattle. Proceedings, p. 1-23. FRANKE, Hubertus et al. An evaluation of parallel job scheduling for ASCI Blue-Pacific. In: ACM/IEEE CONFERENCE ON SUPERCOMPUTING, 99, 1999, Portland. Proceedings, artigo n. 45. FREITAS, Edison P. et al. Dynamic reconfigurable task schedule support towards a reflective middleware for sensor network. In: INTERNATIONAL SYMPOSIUM ON PARALLEL AND DISTRIBUTED PROCESSING WITH APPLICATIONS, 08, 2008, Sydney. Proceedings, p. 886-891.
82
GÓES, Luis F. W.; MARTINS, Carlos A. P. S. RJSSim: a reconfigurable job scheduling simulator for parallel processing learning, ASEE/IEEE FRONTIERS IN EDUCATION CONFERENCE, 33, 2003, Colorado. Paper, p. F3C3-F3C8. GÓES, Luis F. W.; MARTINS, Carlos A. P. S. Reconfigurable gang scheduling algorithm. In: WORKSHOP ON JOB SCHEDULING STRATEGIES FOR PARALLEL PROCESSING, 10, 2004a, New York. Paper, p.81-101. GÓES, Luis F. W.; MARTINS, Carlos A. P. S. Proposta e desenvolvimento de um algoritmo reconfigurável de escalonamento paralelo de tarefas. 2004b. 141f. Dissertação (Mestrado), Pontifícia Universidade Católica de Minas Gerais, Programa de Pós-Graduação em Engenharia Elétrica, Belo Horizonte. GÓES, Luis F. W.; RAMOS, Luiz E. S.; MARTINS, Carlos A. P. S. ClusterSim: a java-based parallel discrete-event simulation tool for cluster computing, IEEE INTERNATIONAL CONFERENCE ON CLUSTER COMPUTING, 2004, 2004, San Diego. Proceedings, p. 401-410. HWANG, Kai; XU, Zhiwei. Scalable parallel computing: technology, architecture, programming, 1st ed. San Francisco: McGraw-Hill Book Company, 1998. JETTE, Morris A. Performance characteristics of gang scheduling in multiprogrammed environments. In: ACM/IEEE CONFERENCE ON SUPERCOMPUTING, 97, 1997, San Jose. Technical Paper, artigo n. 54. KWOK, Yu K.; AHMAD, Ishfaq. Static scheduling algorithms for allocating directed task graphs to multiprocessors, ACM Computing Surveys, v. 31, n. 4, p. 406-471, Dec. 1999. LOS ALAMOS NATIONAL LAB. Laboratório Los Alamos national lab nos EUA. Disponível em <http://www.lanl.gov/> Acesso em: 1 mar. 2011 MARTINS, Carlos A. P. S. et al, Computação reconfigurável: conceitos, tendências e aplicações. In: CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 23. JORNADA DE ATUALIZAÇÃO EM INFORMÁTICA, 22, 2003, Campinas. Anais... Cap. 8, p. 339-388. MAUI CLUSTER SCHEDULER. Link do Projeto Open Source do Escalonador de tarefas Maui cluster scheduler. Disponível em <http://www.clusterresources.com/products/maui/> Acesso em: 1 mar. 2011
MONTANA, David; HUSSAIN, Talib; VIDAVER, Gordon. A genetic-algorithm-based reconfigurable scheduler. In: DAHAL, Keshav P.; TAN, Kay C.; COWLING, Peter I. (Org.). Studies in computacional intelligence: evolutionary scheduling, Warsaw: Springer, 2007. v. 49, cap. 21, p. 577-611.
OUSTERHOUT, John K. Scheduling techniques for concurrent systems. In: INTERNATIONAL CONFERENCE ON DISTRIBUTED SYSTEMS, 3, 1982, Miami. Proceedings, p. 22-30.
83
PAN, Zexin; WELLS, Buren E. Hardware supported task scheduling on dynamically reconfigurable SoC architectures. IEEE Transactions on Very Large Scale Integration Systems, v. 16, n. 11, p. 1465-1474, Nov. 2008. SANTOS, Lesandro P.; SILVA, João P. D.; GÓES, Luis F. W. Técnica de caracterização de cargas de trabalho de supercomputadores para predição do comportamento de tarefas paralelas. REIC - Revista Eletrônica de Iniciação Científica, Brasil, ano 9, n. 1, março, 2009. Disponível em: <http://portal.sbc.org.br/index.php?language=1&subject=101&content= article&option=pdf&aid=632 >. Acesso em: 24 nov. 2009. STERLING, Thomas; STARK, Dylan. A high-performance computing forecast: partly cloudy. Computing in Science & Engineering, v. 11, n. 4, p. 42-49, Jul. 2009. THE STANDARD WORKLOAD FORMAT. Link do laboratório experimental systems lab da universidade The Hebrew University que detalha o formato padrão de carga de trabalho SWF (Standard Workload Format). Disponível em <http://www.cs.huji.ac.il/labs/parallel/workload/swf.html/> Acesso em: 1 mar. 2011 YAMIN, Adenauer C. Escalonamento em sistemas paralelos e distribuídos. In: ESCOLA REGIONAL DE ALTO DESEMPENHO, 1, 2001, Gramado. Anais… p.75-126. WISEMAN, Yair; FEITELSON, Dror G. Paired gang scheduling. IEEE Transactions Parallel & Distributed Systems, v. 14, n. 6, pp. 581-592, Jun. 2003. ZHANG, Yanyong et al. Improving parallel job scheduling by combining gang scheduling and backfilling techniques. In: IEEE INTERNATIONAL PARALLEL AND DISTRIBUTED PROCESSING SYMPOSIUM, 14, 2000, Cancun. Paper, p.133-142. ZHOU, Bing B. et al. An efficient resource allocation scheme for gang scheduling. In: IEEE COMPUTER SOCIETY INTERNATIONAL WORKSHOP ON CLUSTER COMPUTING, 1, 1999, Melbourne. Proceedings, p. 187-194.