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 RECONFIGURÁVEIS DE TAREFAS PARALELAS FUNDAMENTADA NA REGULARIDADE TEMPORAL DA CARGA DE TRABALHO Belo Horizonte 2011
84
Embed
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS … · Para isso, utilizamos o algoritmo Reconfigurable Gang Scheduling Algorithm ... SJF - Short Job First SMP - Symmetric Multi Processor
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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."
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
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
* 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
* 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.