PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS … · Para isso, utilizamos o algoritmo Reconfigurable...

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




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




Dissertação apresentada ao Programa de Pós-Graduação em Engenharia Elétrica da Pontifícia Universidade Católica de Minas Gerais, como requisito parcial para obtenção do título de Mestre em Engenharia Elétrica.

__________________________________________________________ Prof. Dr. Carlos Augusto Paiva da Silva Martins (Orientador) – PUC Minas

__________________________________________________________ Prof. Dr. Adriano César Machado Pereira – CEFET/MG

__________________________________________________________ Prof. Dr. Carlos Alberto Marques Pietrobon – PUC Minas

Belo Horizonte, 26 de abril de 2011.

AGRADECIMENTOS

Agradeço a todos que, de alguma forma, ajudaram na realização desta pesquisa. Em

especial ao meu orientador Carlos Augusto e ao meu co-orientador Luis Fabrício pelo apoio,

paciência, ajuda e orientação durante o período de realização desta pesquisa e principalmente

pela amizade de ambos e pelas experiências profissionais e pessoais passadas. Agradeço aos

meus pais, meus irmãos e minha família pela criação que tive e pelo apoio, amor e amizade

que sempre recebi. A minha namorada Raquel pelo amor, paciência e torcida. Agradeço a

meus amigos pela amizade e força. E a todos por sempre acreditarem em mim e por

entenderem os momentos em que não estive presente, os quais investi na realização desta

pesquisa.

Aos amigos de mestrado e pesquisa, agradeço pela ajuda nos trabalhos e pelo

companheirismo em diversos momentos. De forma especial ao Lesandro Santos pela ajuda

dada na realização desta pesquisa.

Um agradecimento especial para a Pontifícia Universidade Católica de Minas Gerais e

ao Programa de Pós-Graduação em Engenharia Elétrica pela formação recebida.

RESUMO

O objetivo principal desta pesquisa é propor e desenvolver um controle de configuração para

escalonadores reconfiguráveis de tarefas paralelas utilizando predição das melhores

configurações e que seja fundamentado no agrupamento e na modelagem estatística das

cargas de trabalho executadas no passado. Para isso, utilizamos o algoritmo Reconfigurable

Gang Scheduling Algorithm (RGSA) e introduzimos no mesmo uma nova camada de controle

de configuração (CCC). Com isso, passamos a utilizar como parâmetros de entrada para a

tomada de decisão do escalonamento do RGSA, a regularidade temporal de acordo com as

características das cargas de trabalho que foram preditas em períodos anteriores. Esta solução

visa propor uma versão do RGSA que seja mais próxima da realidade e que seja possível e

viável de se implementar em sistemas reais. A nossa meta principal é, então, uma nova

camada CCC do RGSA utilizando predição das configurações fundamentada na análise,

agrupamento e modelagem estatística das cargas de trabalho executadas no passado. Desta

forma, implementamos nesta pesquisa uma nova CCC baseada em regularidade temporal e

que utiliza rastros de cargas de trabalho reais executadas em períodos de tempo diferentes

para identificar as características dessas cargas. De posse dessas informações das cargas

referentes ao passado, a CCC pode tomar melhores decisões. Além disto, propomos um novo

mecanismo do RGSA de alteração de configurações da camada CCC. A principal

contribuição deste trabalho é a apresentação de um novo controle de configuração para

escalonadores reconfiguráveis de tarefas paralelas que utiliza a predição baseada na

regularidade temporal das cargas de trabalho executadas no passado. Este controle foi

implementado na Camada de Controle de Configuração (CCC) do RGSA, que chamamos de

CCC Proposta. Este novo controle é uma evolução da CCC do RGSA Original, a qual realiza

a reconfiguração do escalonador baseado na anotação das cargas que são enviadas juntamente

com a própria carga no momento de submissão. O RGSA com a CCC Proposta está mais

próximo da realidade com a inclusão do novo controle de configuração proposto nesta

pesquisa. O RGSA Proposto não necessita da anotação das cargas para escolher a

configuração que o escalonador irá utilizar, pois utilizando este novo controle de

configuração, usa a predição fundamentada em agrupamento e modelagem estatística da carga

de trabalho para predizer as configurações. Este controle se baseia nas execuções de cargas de

trabalho passadas para as tomadas de decisão utilizando a “Técnica de Caracterização de

Cargas de Trabalho de Supercomputadores”.

Palavras-chave: Computação reconfigurável, Escalonador de tarefas paralelas, Escalonador

reconfigurável de tarefas.

ABSTRACT

The main objective of this research is to propose and develop a configuration control for

reconfigurable parallel task schedulers using prediction of the best settings and based on the

clustering and statistical modeling of workloads run in the past. We used the algorithm

Reconfigurable Gang Scheduling Algorithm (RGSA) and introduced a new layer in the same

configuration control layer (CCC). Thus, we now use as input parameters for decision making

of RGSA scheduling, the temporal regularity according to the characteristics of the workloads

that were predicted in previous periods. This solution aims to propose a version of RGSA that

is closer to reality and that make possible and feasible to implement in real systems. Our main

goal is a new CCC layer of RGSA with prediction using the settings based on the analysis,

clustering and statistical modeling of workloads run in the past. So in this research we

implemented a new CCC based on temporal regularity and using real workloads traces run in

different time periods to identify the characteristics of these loads. With this information of

workloads relating to the past, the CCC can make better decisions. In addition, we propose a

new mechanism for RGSA of changing the layer settings of CCC. The main contribution of

this work is to present a new configuration control for reconfigurable parallel task schedulers

using the prediction based on temporal regularity of workloads run in the past. This control

was implemented at Configuration Control Layer (CCC) of RGSA and we call it as Proposed

CCC. This new control is an evolution of CCC from Original RGSA, which performs the

reconfiguration scheduler based on the annotation of the loads that are sent along with the

load itself at the time of submission. The RGSA with the Proposed CCC is closer to the

reality with the addition of these new control configuration proposed on this research. The

Proposed RGSA doesn’t need any load annotation to choose the configuration that the

scheduler will set, because when using this new configuration control it will use the

configuration based on clustering and statistical modeling of the workload to predict settings.

This control is based on the execution of workloads in the past to make decision using the

"Characterization Technique of Supercomputer Workloads."

Keywords: Reconfigurable Computing, Parallel Task Scheduler, Reconfigurable Task

Scheduler.

LISTA DE FIGURAS

FIGURA 1 - Modelo de Algoritmo Reconfigurável...................................................... 29

FIGURA 2 - Uma das configurações do RGSA............................................................ 30

FIGURA 3 - Representação simplificada do RGSA Original....................................... 34

FIGURA 4 - Proposta de solução para a CCC do RGSA - RGSA com CCC

Proposta..................................................................................................... 36

FIGURA 5 - Exemplo de Regularidade Temporal de cargas de trabalho...................... 36

FIGURA 6 - Parte de arquivo sintético .WKL com dados de um intervalo do dia 0 de

uma semana e das horas 0 a 7................................................................... 38

FIGURA 7 - Fluxo de geração da CCC Proposta para uma carga, composto pelas

Fases de Predição e de Execução.............................................................. 41

FIGURA 8 - Parte do arquivo .SWF referente à carga HPC2N..................................... 46

FIGURA 9 - Parte do arquivo .LOG referente à carga HPC2N mostrada na

Figura 8..................................................................................................... 46

FIGURA 10 - Fluxo de geração da CCC Proposta na Fase de Predição (modo

probabilístico utilizando agrupamento e modelagem estatística) para

carga de Janeiro/2000............................................................................... 47

FIGURA 11 - Fase de Execução (modo determinístico) para carga de

Fevereiro/2000.......................................................................................... 48

FIGURA 12 - Estrutura de testes de verificação do RGSA com a CCC Proposta........ 49

FIGURA 13 - Comparação de esforço para calcular RGSA Ideal e Aproximado......... 67

LISTA DE GRÁFICOS

GRÁFICO 1 - Preditor gerado para a Carga HPC2N.................................................... 56

GRÁFICO 2 - Preditor gerado para a Carga LANLCM5.............................................. 57

GRÁFICO 3 - Preditor gerado para a Carga SDSC....................................................... 59

GRÁFICO 4 - Tempo de execução para a carga HPC2N.............................................. 61

GRÁFICO 5 - Tempo de execução para a carga LANLCM5........................................ 63

GRÁFICO 6 - Tempo de execução para a carga SDSC................................................. 65

GRÁFICO 7 - Comparativo dos tempos de execução para a carga HPC2N

(melhor tempo, pior tempo, RGSA com a CCC Proposta e RGSA

Aproximado)........................................................................................... 68

GRÁFICO 8 - Comparativo dos tempos de execução para a carga LANLCM5


Aproximado)........................................................................................... 69

GRÁFICO 9 - Comparativo dos tempos de execução para a carga SDSC


Aproximado)........................................................................................... 70

LISTA DE QUADROS

QUADRO 1 - Exemplo de temporalidade com período de uma semana e intervalo

em horas da semana.................................................................................. 38

QUADRO 2 - Configurações do RGSA Original.......................................................... 40

QUADRO 3 - Exemplo de tabela de configurações da nova CCC Proposta para o

RGSA com intervalos em horas da semana e período de 1 semana......... 42

LISTA DE TABELAS

TABELA 1 - Médias por hora referentes às características das cargas utilizadas na

Fase de Predição....................................................................................... 50

TABELA 2 - Configurações utilizadas nos resultados da carga HPC2N - Fase de

Predição..................................................................................................... 57

TABELA 3 - Configurações utilizadas nos resultados da carga LANLCM5 - Fase de

Predição..................................................................................................... 58

TABELA 4 - Configurações utilizadas nos resultados da carga SDSC - Fase de

Predição..................................................................................................... 59

TABELA 5 - Tempo de execução HPC2N - RGSA com a CCC Proposta em relação

às 12 configurações fixas.......................................................................... 62

TABELA 6 - Tempo de execução LANLCM5 - RGSA com a CCC Proposta em

relação às 12 configurações fixas............................................................. 64

TABELA 7 - Tempo de execução SDSC - RGSA com a CCC Proposta em relação

às 12 configurações fixas.......................................................................... 66

TABELA 8 - Dados comparativos das cargas de trabalho contendo as médias das

características por hora utilizadas na Predição, obtidas com modelagem

estatística, e Execução.............................................................................. 72

TABELA 9 - Comparação entre as configurações fixas e o RGSA com a CCC

Proposta para as cargas............................................................................. 73

TABELA 10 - Tempo médio de execução das cargas de trabalho com as 12

configurações fixas comparados ao RGSA com a CCC Proposta

utilizadas na execução............................................................................... 75

LISTA DE SIGLAS

CB - Camada Básica (do algoritmo RGSA)

CCC - Camada de Controle de Configuração (do algoritmo RGSA)

COTS - Commodity-Off-The-Shelf

CPI - Ciclos por Instrução

CR - Camada Reconfigurável (do algoritmo RGSA)

DJM - Distributed Job Manager

EP - Elemento de Processamento

FCFS - First Come First Served

GSA - Gang Scheduling Algorithm

GUR - Grid Universal Remote

HPC - High Performance Computing

HPC2N - High Performance Computing Center North

.WKL - extensão de arquivos de workload

LANL - The Los Alamos National Lab

LSDC - Laboratório de Sistemas Digitais e Computacionais

MIMD - Multiple Instruction Multiple Data

MISD - Multiple Instruction Single Data

PPGEE - Programa de Pós-Graduação em Engenharia Elétrica

RGSA - Reconfigurable Gang Scheculing Algorithm

SCI - Scalable Coherent Interface

SDSC - The San Diego Supercomputer Center

SIMD - Single Instruction Multiple Data

SISD - Single Instruction Single Data

SJF - Short Job First

SMP - Symmetric Multi Processor

SO - Sistema Operacional

SSI - Single System Image

SWF - Standard Workload Format

.SWF - extensão de arquivos do padrão SWF (Standard Workload Format)

SUMÁRIO

1 INTRODUÇÃO......................................................................................................... 14 1.1 Contexto da Pesquisa............................................................................................. 14 1.2 Problema Motivador.............................................................................................. 17 1.3 Hipótese de Solução............................................................................................... 18 1.4 Objetivos e Metas................................................................................................... 19 1.5 Justificativa............................................................................................................. 20 1.6 Escopo..................................................................................................................... 21 1.7 Organização do restante do texto......................................................................... 22 2 REVISÃO BIBLIOGRÁFICA................................................................................. 23 2.1 Arquiteturas Paralelas........................................................................................... 23 2.2 Escalonamento de Tarefas Paralelas.................................................................... 24 2.3 Escalonamento de Gangues................................................................................... 26 2.4 Reconfigurable Gang Scheduling Algorithm...................................................... 27 2.5 Trabalhos Relacionados........................................................................................ 30 3 PROPOSTA DE SOLUÇÃO.................................................................................... 32 3.1 Contexto da Proposta de Solução......................................................................... 32 3.2 Análise da Camada de Controle de Configuração Original.............................. 33 3.3 Proposta de Solução............................................................................................... 35 3.4 Considerações Finais.............................................................................................. 43 4 RESULTADOS.......................................................................................................... 44 4.1 Ambiente de Experimentação............................................................................... 44 4.1.1 Cargas de Trabalho.............................................................................................. 44 4.1.2 Análise Comparativa das Cargas de Trabalho Utilizadas na Fase de

Predição................................................................................................................ 49 4.1.3 Configuração dos Experimentos......................................................................... 52 4.1.4 Recursos Computacionais.................................................................................... 54 4.2 Fase de Predição..................................................................................................... 55 4.3 Fase de Execução (Operação)............................................................................... 60 4.3.1 Fase de Execução com a Carga HPC2N............................................................ 60 4.3.2 Fase de Execução com a Carga LANLCM5..................................................... 62 4.3.3 Fase de Execução com a Carga SDSC............................................................... 64 4.4 Análise dos Resultados........................................................................................... 66 4.5 Considerações Finais.............................................................................................. 75 5 CONCLUSÃO........................................................................................................... 77 5.1 Discussão dos Resultados....................................................................................... 77 5.2 Principais Contribuições....................................................................................... 78 5.3 Trabalhos Futuros.................................................................................................. 79 REFERÊNCIAS........................................................................................................... 81

14

1 INTRODUÇÃO

Neste capítulo, é descrito inicialmente o contexto da pesquisa. Posteriormente,

apresentamos o problema motivador e a hipótese de solução desta pesquisa. Os próximos

tópicos são os objetivos e metas; a justificativa, contendo a importância e a relevância; e o

escopo da pesquisa. Finalmente, apresentamos a organização do restante do texto desta

dissertação.

1.1 Contexto da Pesquisa

Nos últimos anos, a demanda por computação de alto desempenho, ou High

Performance Computing (HPC) tem aumentado significativamente. Assim como o tempo de

processamento tem sido um fator de importância, o custo e a qualidade dos resultados

produzidos também são importantes. Deste modo, empresas e instituições de ensino vêm

pesquisando e investindo na área de sistemas de computação de alto desempenho para atender

às suas demandas. Esses investimentos têm sido realizados principalmente em sistemas de

computação distribuídos e paralelos (GÓES; MARTINS, 2004b; STERLING; STARK,

2009).

Dois objetos importantes na análise da operação de um sistema de computação

paralelo são a sua arquitetura paralela e a sua carga de trabalho, que é executada pelo sistema

de computação paralelo. Como exemplos de arquiteturas paralelas, podemos citar os

multiprocessadores e os multicomputadores.

Os multiprocessadores são sistemas compostos por vários elementos de processamento

(EP). Quando falamos sobre EP, nos referimos a algum componente ou dispositivo que

possua a característica de processar dados. Nos multiprocessadores, os EPs possuem um

mesmo espaço de endereçamento de memória e compartilham por sua vez uma mesma

memória. Assim, a comunicação é feita por meio de leituras e escritas em variáveis na

memória compartilhada. Como exemplos, temos grande parte dos processadores multi-core; e

Symmetric Multi Processor (SMP), processadores simétricos interligados e que compartilham

um mesmo espaço de endereçamento de memória.

Os multicomputadores são sistemas compostos por nodos interligados entre si por

meio de uma rede de interconexão. Cada nodo possui seu(s) próprio(s) EP(s) e seu próprio

espaço de endereçamento de memória. A comunicação acontece via troca de mensagens

15

utilizando o meio de interligação existente. Como exemplos de multicomputadores, podemos

citar os aglomerados de computadores (comumente conhecidos por clusters); e as grades

computacionais.

Temos então alguns aspectos importantes:

a) a arquitetura paralela do sistema de computação paralelo;

b) o código executável/rotina ou aplicação;

c) os dados de entrada da aplicação;

d) o modo de interação do usuário.

O código executável/rotina é executado(a) sobre a arquitetura paralela a fim de

processar os dados de entrada da aplicação de acordo com o modo de interação do usuário. E

a junção do código executável/rotina, os dados a serem processados e o modo de interação do

usuário chamaremos de carga de trabalho. Para completar o sistema de computação,

precisamos de uma interface e/ou de um sistema operacional (SO) para gerenciar a execução

da carga de trabalho pelo sistema de computação paralelo.

O sistema operacional possui um serviço de escolha para fazer com que a carga de

trabalho seja executada em determinado momento e em determinado EP. Esse serviço é

chamado de escalonamento de tarefas. Assim, o escalonador de tarefas é o módulo ou camada

que faz a escolha de qual EP irá executar cada uma das tarefas da carga de trabalho. As

decisões ou simplesmente as escolhas que o escalonador deve realizar são várias, entre as

quais podemos destacar as relacionadas às políticas de escalonamento. Então, uma boa

política de escalonamento é aquela que utiliza da forma mais eficiente os recursos

computacionais existentes (BUYYA, 1999; HWANG; XU, 1998; EL-REWINI; ALI; LEWIS,

1995; FRACHTENBERG; SCHWIEGELSHOHN, 2007), levando em consideração as

características das cargas de trabalho executadas.

Vale ressaltar a importância do escalonador em satisfazer o tempo, o custo e a

qualidade dos resultados produzidos em um sistema de computação paralelo. Assim, a escolha

de uma política de escalonamento adequada aos recursos computacionais e às cargas de

trabalho submetidas é de extrema importância. A escolha de uma política de escalonamento

que seja a mais apropriada ao problema se dá por meio de análises das características das

cargas de trabalho que serão executadas e dos recursos computacionais existentes.

16

Com relação ao escalonamento, existem dois tipos principais: o escalonamento

estático, que faz a distribuição das tarefas entre os EPs antes do início da execução das

tarefas; e o escalonamento dinâmico, que faz a distribuição das tarefas em tempo de execução.

Em ambos os casos (estático ou dinâmico), os sistemas de computação não

caracterizados como sistemas de tempo real, não podem garantir um desempenho desejado,

ou mesmo ideal. Isso devido à heterogeneidade das cargas de trabalho e ao comportamento

dinâmico dos sistemas de computação (GÓES; MARTINS, 2004b).

Com o intuito de melhorar a qualidade do escalonamento, várias soluções foram

propostas e desenvolvidas. Dentre as soluções, destacamos o algoritmo de escalonamento

paralelo de tarefas denominado Algoritmo de Escalonamento Reconfigurável de Gangues

(RGSA - Reconfigurable Gang Scheduling Algorithm) (GÓES; MARTINS, 2004a; GÓES;

MARTINS, 2004b), que fará parte da nossa pesquisa.

O RGSA é um algoritmo que se baseia no algoritmo de escalonamento de gangues de

Ousterhout (OUSTERHOUT, 1982), o Gang Scheduling Algorithm (GSA). O RGSA se

diferencia do algoritmo de escalonamento de gangues de Ousterhout por possibilitar a

utilização de diferentes configurações de escalonamento em tempo de execução e que o

algoritmo se reconfigure automaticamente de acordo com as regras detalhadas no algoritmo. E

isso é importante pelo fato de existirem variações nas cargas de trabalho e nos sistemas de

computação, além do comportamento dinâmico dos sistemas de computação. Contudo, um

fator a se considerar é que quanto mais complicado ou quanto mais informação se necessitar

para a tomada de decisão da política de escalonamento, maior será o consumo dos recursos

que o escalonador está gerenciando. Dentre os recursos consumidos destacamos os EPs, as

memórias e a largura de banda da rede de interconexão ou do barramento utilizados para

conectar os EPs. O RGSA foi implementado utilizando simulação no ClusterSim (simulador

de escalonamento paralelo de tarefas em aglomerado de computadores) (GÓES; RAMOS;

MARTINS, 2004).

A principal vantagem do RGSA é o alto desempenho devido à flexibilidade e

adaptabilidade na execução das cargas de trabalho. Ele possui uma Camada de Controle de

Configuração (CCC) que permite que as configurações do escalonador sejam alteradas

dinamicamente em tempo de execução. Dessa forma, o RGSA é reconfigurado e adequado

com a configuração da política de escalonamento selecionada pelo algoritmo, dentre outras

configurações disponíveis, para cada carga de trabalho executada.

E citamos duas desvantagens como principais. A primeira é a necessidade da carga de

trabalho estar etiquetada, ou conter anotação (termo mais utilizado atualmente), antes de sua

17

execução. Para o RGSA, as anotações são os parâmetros de entrada que, neste caso, são as

características da carga de trabalho. A segunda desvantagem é a camada CCC não possuir

mecanismos de auto-adaptação.

Porém, o RGSA foi proposto utilizando as características ideais, ou seja, utilizando

sempre as melhores configurações para cada carga de trabalho. Sendo assim, uma

implementação real do RGSA, da maneira como foi originalmente concebido, não é uma

opção viável de implementação, visto que nem sempre conseguimos saber antecipadamente as

características das cargas de trabalho a serem executadas. E, para conseguirmos essas

informações, é necessário caracterizar e gerar as anotações da carga de trabalho. Esta é uma

das principais dificuldades em se implementar o RGSA num sistema de computação paralelo

real, pois a camada CCC precisa receber a carga de trabalho com as suas respectivas

anotações para que o RGSA possa configurar o escalonador com as melhores configurações

para esta carga para a execução da mesma.

1.2 Problema Motivador

A motivação dessa pesquisa teve origem na leitura da dissertação de mestrado

“Proposta e Desenvolvimento de um Algoritmo Reconfigurável de Escalonamento Paralelo de

Tarefas” (GÓES; MARTINS, 2004b) onde os problemas foram solucionados com simulação

usando o simulador ClusterSim. Nesta dissertação, o aluno propôs o RGSA, um algoritmo de

escalonamento de tarefas paralelas baseado no Gang Scheduling Algorithm (GSA) e que

utiliza conceitos de computação reconfigurável aplicados no algoritmo de escalonamento

paralelo de tarefas. Para tal, foi desenvolvido na pesquisa um simulador discreto por eventos

para validar o escalonador. O simulador desenvolvido para validar a proposta do RGSA,

simula também um ambiente paralelo de cluster, onde o escalonador foi simulado.

O escalonador RGSA possui a camada de controle de configuração (CCC) ideal ou

ótima. Isso porque o escalonador tem como premissa receber juntamente com a carga de

trabalho a ser executada no ambiente, uma anotação contendo informações das características

da carga de trabalho, a qual servirá como parâmetro de entrada da CCC. Esta anotação da

carga de trabalho faz com que a mesma seja executada com a melhor configuração disponível

no escalonador para a carga em questão. Assim, o RGSA considera que existe algum módulo

externo que executa o serviço de fornecer os valores corretos das características das cargas de

trabalho (anotações) ou simplesmente gere as anotações das cargas de trabalho corretamente.

Desta forma, essas anotações são utilizadas como parâmetros de entrada da CCC. Isso é a

18

condição ideal, porém é a principal dificuldade para se implementar o RGSA na prática, pois

a carga tem que ser analisada como um todo antes de ser executada; e isso acarreta em muita

sobrecarga para o RGSA.

O problema motivador do trabalho é, então, a dificuldade em se implementar a CCC

do RGSA utilizando como parâmetros de entrada a anotação com as informações necessárias

para escalonar a carga e obtidas com o mínimo de sobrecarga possível. Porém, um fator

importante a se considerar é que nos escalonadores reconfiguráveis existe essa dificuldade em

se obter um mecanismo que extráia as informações da carga de trabalho e reconfigure o

escalonador dinamicamente. Assim, o propósito desta pesquisa é a de se desenvolver uma

CCC mais realística, que nos proporcione a menor perda de desempenho possível e que esteja

preparada para ser implementada na prática.

1.3 Hipótese de Solução

Conforme citado anteriormente, o RGSA necessita que as cargas de trabalho

contenham anotações para que a CCC possa configurar o RGSA com as configurações mais

eficientes em termos de desempenho de escalonamento para a respectiva carga. Para tirar a

dependência do RGSA das cargas de trabalho conterem anotações, a nossa proposta de

solução é desenvolver um controle de configuração para escalonadores reconfiguráveis de

tarefas paralelas e incluí-lo no RGSA. Esse controle de configuração utilizará predição das

configurações, fundamentada no agrupamento e modelagem estatística das cargas de trabalho

executadas no passado para tomada de decisão. Assim, uma nova camada de controle de

configuração (CCC) para o RGSA será desenvolvida e ela será fundamentada na regularidade

temporal das cargas de trabalho. A solução vai se basear nas características das cargas de

trabalho que foram executadas e escalonadas no sistema de computação paralelo no passado

para que possamos utilizar como parâmetros de entrada para a CCC.

A hipótese de solução a ser testada é que as cargas de trabalho executadas nos

mesmos períodos e intervalos de tempo (no caso desta pesquisa dias da semana e horários)

apresentam alguma homogeneidade em termos de características ideais de execução e/ou

escalonamento em função de regularidade temporal das cargas de trabalho. Com isso

queremos mostrar que é possível escalonar cargas de trabalho futuras usando configurações

preditas a partir de um modelo produzido por agrupamento e modelagem estatística de cargas

de trabalho do passado.

19

Assim, extraímos informações de cargas de trabalho de um determinado período que

foram executadas em um sistema de computação paralelo. Depois, agrupamos e modelamos

essa carga de trabalho do passado utilizando análise estatística. A partir daí, executamos estas

cargas de trabalho modeladas utilizando simulação com o ClusterSim e extraímos

informações referentes a estas execuções. Com essas informações conseguimos predizer as

configurações mais indicadas para cada intervalo da carga. Após, extraímos informações de

cargas de trabalho de períodos posteriores deste mesmo sistema de computação utilizado. No

final, executamos a carga de trabalho mais recente utilizando as configurações preditas com a

carga de trabalho do passado.

1.4 Objetivos e Metas

Com base no problema citado anteriormente, o nosso objetivo principal ou geral é

propor e desenvolver um controle de configuração para escalonadores reconfiguráveis de

tarefas paralelas que utilize predição das configurações fundamentada em agrupamento e

modelagem estatística das cargas de trabalho executadas no passado. Para isso, iremos utilizar

o RGSA nesta pesquisa e iremos alterar sua camada de controle de configuração (CCC). Com

isso, utilizaremos como parâmetros de entrada para a tomada de decisão do escalonamento do

RGSA o horário de submissão de cada tarefa da carga de trabalho. Esta solução visa propor

uma versão do RGSA que seja mais próxima da realidade e que seja possível e viável de se

implementar em sistemas reais.

A nossa meta principal é, então, uma nova camada CCC do RGSA utilizando predição

das configurações fundamentada na análise, agrupamento e modelagem estatística das cargas

de trabalho executadas no passado. Desta forma, queremos implementar uma CCC baseada

em regularidade temporal que utilize rastros de cargas de trabalho reais executadas em

períodos de tempo diferentes para identificar as características dessas cargas. De posse dessas

informações das cargas referentes ao passado, a CCC pode tomar melhores decisões. Além

disto, propomos um novo mecanismo do RGSA de alteração de configurações da camada

CCC.

Como objetivos secundários temos: i) análise inicial do RGSA Original; ii) análise

inicial de caracterização de cargas de trabalho; iii) análise detalhada da camada CCC do

RGSA Original; iv) proposta de um mecanismo de alteração das configurações da camada

CCC do RGSA; v) aplicação de técnicas de otimização na proposta e desenvolvimento da

nova camada CCC do RGSA; vi) comparação da nossa CCC Proposta com a CCC Proposta

20

Ideal ou Ótima (que utiliza as configurações mais eficientes possíveis em termos de

desempenho para cada carga de trabalho).

1.5 Justificativa

A justifi cativa para o trabalho é que o escalonamento é importante para o

desempenho dos clusters e sistemas de computação paralelos em geral, pois é ele o

responsável por tomar as decisões a respeito da execução das tarefas. A nova proposta de

camada de controle de configuração (CCC) do RGSA, após sua implementação, poderá ajudar

nos estudos de melhoria na área de escalonamento paralelo de tarefas e no maior uso de

reconfiguração em software. Além disso, pode proporcionar maior qualidade nos resultados

produzidos e em pesquisas, pois pode reduzir bastante os tempos de execução das cargas de

trabalho nos sistemas de computação paralelos. Assim, isso será importante para as diversas

áreas do conhecimento que utilizam computação de alto desempenho, em especial

computação paralela, podendo proporcionar maior desempenho.

O escalonamento de tarefas paralelas é um dos fatores importantes para que o sistema

de computação paralelo possa apresentar um desempenho de execução satisfatório. Por isso,

estudos nesta área possuem sua importância para que os escalonadores sejam aprimorados e

para que, desta forma, os usuários de sistemas de computação paralelos possam se beneficiar

dessa evolução. Dentre os usuários beneficiados estão os de âmbito empresarial, profissional,

acadêmico e de aprendizado, envolvendo principalmente as empresas e as universidades.

O RGSA, como objeto desta pesquisa, produziu resultados de qualidade escalonando

tarefas no simulador ClusterSim. Além disso, o RGSA foi escolhido, porque tínhamos acesso

ao código fonte do escalonador e do simulador utilizado na verificação e testes do RGSA.

Também, por termos acesso ao próprio desenvolvedor da aplicação, que é vinculado ao nosso

laboratório de pesquisa. Outro fator importante a ressaltar é o fato de o RGSA ter sido

desenvolvido com o próprio ClusterSim. Como existe uma dificuldade grande em se

implementar a camada de controle de configuração (CCC) do RGSA, a proposta de uma nova

CCC mais simples passa a tornar a utilização do RGSA num ambiente real não simulado mais

próxima de se concretizar. Isso porque a caracterização da carga de trabalho usando

regularidade temporal passa a ser uma alternativa mais viável e realística do que a proposta

original.

Foram realizadas pesquisas em sites de busca e em publicações de eventos e

periódicos da área sobre escalonadores de tarefas paralelas e o uso de reconfigurabilidade

21

aplicado em escalonamento. Foram encontrados trabalhos relacionados com algumas das

áreas desta pesquisa, porém, os relacionados diretamente com todas as áreas da pesquisa

foram apenas os trabalhos (GÓES; MARTINS, 2003; GÓES; MARTINS, 2004a; GÓES;

MARTINS, 2004b). Este fato aumenta a importância da pesquisa.

Como relevância deste trabalho, podemos destacar a continuidade da pesquisa da

dissertação de mestrado “Proposta e Desenvolvimento de um Algoritmo Reconfigurável de

Escalonamento Paralelo de Tarefas” (GÓES; MARTINS, 2004b). Essa pesquisa foi realizada

no Laboratório de Sistemas Digitais e Computacionais (LSDC) do Programa de Pós-

Graduação em Engenharia Elétrica (PPGEE) da PUC Minas. Um dos trabalhos futuros da

pesquisa (GÓES; MARTINS, 2004b) é a implementação do RGSA em um ambiente real.

Assim, essa dissertação é uma etapa para permitir que a implementação do RGSA em um

ambiente real seja desenvolvida em algum trabalho futuro. Além disso, a possibilidade de se

implementar o RGSA num sistema de computação paralelo não simulado pode proporcionar a

realização de uma análise entre um ambiente de simulação (RGSA simulado utilizando o

ClusterSim) e um ambiente de experimentação real não simulado (RGSA implementado num

sistema de computação não simulado). Assim, pode ser realizada uma análise de desempenho

entre sistemas de computação simulados e não simulados. Outra análise que pode ser

realizada é a utilização de reconfigurabilidade em escalonadores de tarefas paralelas nos

sistemas de computação paralelos e do ganho que podemos alcançar com esse uso. Isso é

importante, pois o tempo gasto com a reconfiguração no escalonamento pode influenciar no

desempenho do próprio escalonamento.

1.6 Escopo

O escopo da pesquisa é o desenvolvimento de um controle de configuração para

escalonadores reconfiguráveis de tarefas paralelas fundamentado na predição das

configurações utilizando agrupamento e modelagem estatística da carga de trabalho executada

no passado. Com isso, mostraremos nesta pesquisa a alteração na camada de controle de

configuração (CCC) do RGSA originalmente concebida. Esta nova camada desenvolvida

possibilitará ao RGSA ser implementado mais facilmente em sistemas de computação reais.

Além disso, a versão do RGSA com a nova CCC poderá ser utilizada com o ClusterSim, o

qual é gratuito e disponível para download no site acadêmico do PPGEE da PUC Minas.

Assim, os alunos, pesquisadores ou profissionais da área poderão estudar e testar o RGSA

com suas próprias cargas de trabalho antes de implementá-lo em seu ambiente paralelo. Hoje

22

isso é possível, porém as cargas de trabalho precisam estar caracterizadas ou serem

caracterizadas antes de serem executadas pelo ClusterSim.

1.7 Organização do restante do texto

A organização deste documento segue a ordem descrita a seguir. No capítulo 2,

revisão bibliográfica, é apresentada a revisão da literatura de algumas das subáreas e os

assuntos que são importantes para o desenvolvimento da pesquisa. São elas: arquiteturas

paralelas, escalonamento de tarefas paralelas, escalonamento de gangues, Reconfigurable

Gang Scheduling Algorithm e principais trabalhos relacionados.

No capítulo 3 são apresentadas a proposta e o desenvolvimento do novo controle de

configuração para escalonadores reconfiguráveis de tarefas paralelas que será utilizado na

nova CCC Proposta do RGSA.

No capítulo 4 são apresentados os resultados obtidos nesta pesquisa após os testes

realizados com o novo controle de configuração da CCC Proposta do RGSA.

No capítulo 5, conclusão, são apresentadas as discussões dos resultados obtidos nesta

pesquisa, as principais contribuições e alguns possíveis trabalhos futuros.

Por fim são apresentadas as referências utilizadas para o desenvolvimento desta

pesquisa.

23

2 REVISÃO BIBLIOGRÁFICA

Neste capítulo é apresentada a revisão bibliográfica das áreas relevantes para nossa

pesquisa. Primeiramente é feita a revisão bibliográfica das arquiteturas paralelas. Em seguida,

escalonamento de tarefas paralelas. Logo após detalharemos dois tipos de escalonamento de

tarefas paralelas, o escalonamento de gangues (GSA) e o escalonamento reconfigurável de

gangues (RGSA). Por fim são apresentados os principais trabalhos relacionados.

2.1 Arquiteturas Paralelas

A taxonomia de Flynn de arquitetura de computadores engloba quatro modelos de

arquiteturas de computadores paralelos (FLYNN, 1966; FLYNN, 1972; ALMASI;

GOTTLIEB, 1994):

a) Single Instruction Single Data – SISD;

b) Single Instruction Multiple Data – SIMD;

c) Multiple Instruction Single Data – MISD;

d) Multiple Instruction Multiple Data – MIMD.

Estes modelos envolvem instruções e dados, podendo ser fluxos únicos ou múltiplos

de instruções sendo executadas utilizando fluxos únicos ou múltiplos de dados. Dentre esses

modelos de computadores paralelos da taxonomia de Flynn destacaremos o modelo de

computador paralelo MIMD dentre os demais, pois é o que iremos utilizar nesta pesquisa. No

modelo de arquitetura de computadores MIMD, vários Elementos de Processamento (EPs)

executam múltiplas instruções utilizando diferentes conjuntos de dados e códigos/rotinas

executáveis como carga de trabalho.

A classificação das arquiteturas paralelas do modelo MIMD pode ser dividida

basicamente em duas classes principais: os multiprocessadores e os multicomputadores.

Um multiprocessador é um computador paralelo composto de um conjunto de EPs que

compartilham uma mesma memória física e um mesmo espaço de endereçamento. Como

meio ou forma de comunicação são utilizadas variáveis compartilhadas em memória. Para a

comunicação são realizadas escritas e leituras nestas variáveis compartilhadas em sua

24

memória feitas pelos processos de uma mesma tarefa (ALMASI; GOTTLIEB, 1994;

BUYYA, 1999; HWANG; XU, 1998).

Já um multicomputador é aquele computador paralelo composto por nodos, sendo que

cada nodo possui sua própria memória física, a qual é independente dos demais nodos. Como

cada nodo possui sua própria memória física, eles não compartilham um mesmo espaço de

endereçamento. Para que ocorra a comunicação, um processo precisa trocar mensagens com

outro nodo por meio de uma rede de interconexão entre eles (BUYYA, 1999; HWANG; XU,

1998). A rede de interconexão pode ser simples e montada com uma rede local padrão

ethernet; ou ser mais complexa utilizando algum outro tipo de interconexão.

Nesta pesquisa, damos destaque para a arquitetura paralela de aglomerado de

computadores ou simplesmente clusters, nome pelo qual são mais conhecidos. Os clusters

fazem parte da classe dos multicomputadores. Um cluster possui todos os seus nodos

trabalhando coletivamente como um sistema único. A idéia é o usuário ter a sensação de estar

visualizando o cluster como uma Imagem de um Sistema Único (Single System Image - SSI).

Assim, o usuário mesmo estando logado em apenas um computador, teria a visão de todos os

serviços oferecidos pelo cluster. Cada nodo do cluster pode ser um SMP, uma estação de

trabalho ou um computador pessoal independente. Ou seja, os desktops ou computadores

pessoais que utilizamos normalmente em casa ou no trabalho podem fazer parte de um

multicomputador deste porte. Os clusters possuem um baixo custo financeiro, visto que são

construídos utilizando componentes de hardware mais baratos e encontrados facilmente em

qualquer loja acessível a todas as pessoas (chamados de hardware do tipo commodity-off-the-

shelf - COTS) e software livre disponível (BUYYA, 1999; HWANG; XU, 1998; ALMASI;

GOTTLIEB, 1994). Apesar do baixo custo, eles podem prover um poder de processamento

elevado dependendo da forma com que aplicações utilizadas são escritas e das políticas de

escalonamento utilizadas.

2.2 Escalonamento de Tarefas Paralelas

O escalonamento de tarefas é um problema no qual um algoritmo procura alocar, ao

longo do tempo, uma carga de trabalho a uma arquitetura. A carga de trabalho é composta por

uma ou mais tarefas. Nos casos de arquiteturas não paralelas, que são os casos mais

comumente encontrados, a arquitetura normalmente é composta por um único processador ou

um processador com um único núcleo. Mas quando falamos em escalonamento paralelo, a

diferença é que o escalonador procura alocar as tarefas ao longo do tempo aos processadores

25

da arquitetura paralela. Nele, os processadores podem ser compartilhados por meio de

compartilhamento de espaço e compartilhamento de tempo. O compartilhamento de espaço

acontece com a divisão ou o compartilhamento dos espaços de memória e demais recursos

computacionais existentes no computador. Já o compartilhamento de tempo, ocorre na divisão

de fatias de tempo de processamento entre os diversos processos que estão sendo executados

em um determinado momento em uma arquitetura computacional. Esses tipos de

compartilhamento utilizam mecanismos amplamente independentes ou ortogonais,

possibilitando uma combinação entre eles (FEITELSON, 1997; HWANG; XU, 1998). E essa

combinação tem impacto direto no desempenho do sistema computacional.

No escalonamento paralelo existem dois tipos principais: estático e dinâmico

(CAMPOS, 1999; EL-REWINI; ALI; LEWIS, 1995; FEITELSON, 1997; KWOK; AHMAD,

1999; YAMIN, 2001).

No escalonamento estático, o escalonador faz o mapeamento das tarefas de maneira a

atribuir tarefas aos EPs. Isso no intuito de minimizar o tempo total de execução das tarefas.

Contudo, isso é feito antes do início da execução, ou seja, em tempo de compilação. Dessa

forma, após o início do processamento, as tarefas permanecem nos processadores aos quais

foram alocadas, até que a execução paralela finalize. Isso caracteriza como não-preemptivas

as estratégias de escalonamento estático. Assim, é necessário que a política de escalonamento

tenha algum tipo de conhecimento com relação às tarefas para não diminuir o desempenho da

execução do sistema. Caso o algoritmo de escalonamento não tenha um bom conhecimento

sobre alguns itens como os citados logo abaixo, isto fará com que o escalonador não tenha um

bom desempenho. Exemplos destes itens são:

a) Tipo das tarefas;

b) Tempo de execução;

c) Relações de dependência;

d) Padrões de comunicação entre as mesmas.

A decisão de escalonamento no caso do escalonamento estático é geralmente

centralizada, não se adaptando ao estado atual ou futuro do ambiente de execução (CAMPOS,

1999; EL-REWINI; ALI; LEWIS, 1995; KWOK; AHMAD, 1999; YAMIN, 2001). É como

se tivéssemos uma lista de pares formada por tarefas e EPs, sendo que esta lista é gerada antes

do início da execução das tarefas. Só que isto não é o ideal no mundo real, pois a mesma

26

política não consegue satisfazer aos requisitos de qualidade, de custo e de tempo de execução

para todas as possíveis combinações de carga de trabalho existentes.

Para o escalonamento paralelo dinâmico, poucas suposições podem ser feitas sobre as

tarefas e os processos antes do início da execução, assim sendo, as tomadas de decisão para o

escalonamento devem ser realizadas somente em tempo de execução. A idéia basicamente é a

de se fazer o ordenamento e a alocação dos processos de uma determinada tarefa durante a

execução da mesma, tendo como meta ou fim, não apenas a redução do tempo de execução da

tarefa, mas também a minimização da sobrecarga de escalonamento. Como sobrecarga de

escalonamento, podemos mencionar o tempo gasto para coleta de informações, para a

distribuição ou até mesmo para a migração das tarefas. Isso mostra que o escalonamento pode

ser preemptivo, distribuído e/ou adaptativo (CAMPOS, 1999; FEITELSON, 1997; KWOK;

AHMAD, 1999; YAMIN, 2001). Voltando ao exemplo da lista de pares, é como se esta lista

fosse sendo formada e atualizada conforme algumas regras pré-estabelecidas a fim de

distribuir as tarefas aos EPs.

2.3 Escalonamento de Gangues

O Gang Scheduling Algorithm (GSA) ou simplesmente escalonamento de gangues, foi

o algoritmo base para o desenvolvimento do RGSA. O GSA, que será detalhado

posteriormente, foi primeiramente desenvolvido e apresentado por Ousterhout

(OUSTERHOUT, 1982). Com o nome inicial de co-escalonamento, teve como objetivo

principal o uso eficiente da espera ocupada das tarefas de sincronização de grão fino. Assim, a

idéia é de se utilizar melhor o tempo em que um processo estiver em espera ocupada

aguardando algum evento ou resposta acontecer. O escalonamento de gangues é uma

combinação de três características (FEITELSON, 1997):

a) Os processos devem ser agrupados em gangues (o sentido de gangue aqui se refere

a processos com alguma característica semelhante: I/O bound, CPU bound,

processos de mesma tarefa, processos que se comunicam entre si, dentre outras);

b) Os processos de uma tarefa executam simultaneamente em processadores distintos;

c) Todos os processos de uma gangue são interrompidos e re-escalonados ao mesmo

tempo, utilizando-se compartilhamento de tempo.

27

Partindo dessas premissas, percebemos que casos de grupos de processos (gangues)

que se comunicam com muita freqüência devem ser agrupados em uma gangue visto que

serão todos escalonados ao mesmo tempo. Normalmente, todos os processos de uma tarefa

são considerados uma gangue (FEITELSON, 1997).

O escalonamento de gangues possui como vantagens principais:

a) Prover tempo de resposta interativo para tarefas com baixo tempo de execução, por

meio de preempção;

b) Evitar que tarefas com alto tempo de execução monopolizem os processadores;

c) Aumentar a utilização do sistema na alocação de recursos (FEITELSON, 1997;

JETTE, 1997);

d) Não necessitar de uma estimativa do tempo de término de uma tarefa (ZHANG,

2000);

e) As tarefas podem ser iniciadas sem ter que esperar que todos os processadores

requeridos sejam desocupados (JETTE, 1997).

O escalonamento de gangues possui como desvantagens principais:

a) A característica de preempção aumenta a sobrecarga na troca de contexto e pode

reduzir o desempenho da cache (FEITELSON, 1997)

b) Possui necessidade de memória e disco adicional devido a várias tarefas

compartilharem os mesmos processadores (BATAT; FEITELSON, 2000)

c) Necessidade de fragmentação de tarefas (FRANKE, 1999; ZHOU, 1999)

d) Os processadores ficam ociosos (escalonamento de gangues restrito) no momento

que os processos realizam I/O ou comunicação bloqueante, (WISEMAN;

FEITELSON, 2003).

2.4 Reconfigurable Gang Scheduling Algorithm

Iremos detalhar um pouco sobre reconfigurabilidade e posteriormente sobre o

algoritmo Reconfigurable Gang Scheduling Algorithm (RGSA) (GÓES; MARTINS, 2004a),

porém, explicaremos primeiramente os conceitos de computação reconfigurável.

Quando comparamos os dispositivos de hardware fixo ou não programáveis (solução

ou paradigma de hardware) com os microprocessadores ou dispositivos programáveis

28

(solução ou paradigma de software), chegamos a algumas conclusões. O hardware fixo

produz um desempenho superior ao dos microprocessadores, porém, como seu

comportamento lógico é único, possui menor flexibilidade. Já com os microprocessadores

acontece o inverso, pois produzem um desempenho menor, porém possuem uma maior

flexibilidade (MARTINS et al, 2003).

Devido ao contraste entre estes dois paradigmas, criou-se um terceiro paradigma

chamado solução ou paradigma em hardware reconfigurável. Esse novo paradigma visa, além

de tudo, buscar unir as vantagens das duas soluções descritas anteriormente, como também

eliminar as suas desvantagens. Dessa forma, possibilita-se um maior desempenho e

flexibilidade unidos em uma mesma solução ou em um mesmo dispositivo (MARTINS et al,

2003).

Assim utilizou-se de conceitos de computação reconfigurável no desenvolvimento do

RGSA a fim de implantar a flexibilidade e adaptabilidade dinâmica no escalonador.

O RGSA é uma adaptação do algoritmo GSA utilizando conceitos de computação

reconfigurável. Um algoritmo que utiliza conceitos de reconfiguração se baseia em três

camadas, assim como mostrado na Figura 1, sendo a primeira chamada de Camada Básica

(CB), a segunda de Camada Reconfigurável (CR) e a terceira de Camada de Controle de

Configuração (CCC). A CB é representada pelas estruturas de dados e conjuntos de quadros.

A CR é aquela que armazena as possíveis configurações da CB. Assim a CCC irá, num

determinado momento preencher cada um dos quadros do conjunto de quadros da CB com

uma configuração da CR. A CCC controla dinamicamente essas configurações dos quadros de

acordo com alguns parâmetros de entrada.

No RGSA os parâmetros de entrada são: o tempo de execução (que pode ser alto ou

baixo), o grau de paralelismo (podendo ser alto ou baixo) e o grau de predominância (valores

60%, 80% ou 100%). O tempo de execução alto é aquele cujo total de instruções executadas

pela tarefa seja igual a 1 bilhão de instruções, enquanto as tarefas com baixo tempo de

execução executam 100 milhões de instruções. Por outro lado, o grau de paralelismo de uma

tarefa é considerado alto se a quantidade de processos da tarefa for maior que 1/4 da

quantidade de processadores do sistema computacional. Caso a quantidade de processos seja

menor ou igual à 1/4 da quantidade de processadores do sistema computacional, o grau de

paralelismo é considerado baixo. Já o grau de predominância da carga é o percentual da

quantidade de tarefas da carga com grau de paralelismo alto, variando entre os valores 60%,

80% ou 100%. Essa métrica foi utilizada nos experimentos realizados para a avaliação de

desempenho do RGSA.

29

Figura 1 - Modelo de Algoritmo Reconfigurável

Fonte: (GÓES; MARTINS, 2004b)

No caso do RGSA, a CB é uma camada contendo uma fila implementada para que as

tarefas que chegam ao ambiente que possui essa política de escalonamento implementada

entrem nesta fila de espera para aguardar o momento de serem executadas. A CR contem

algumas configurações dos quadros da CB como: formas de empacotamento (primeiro

encaixe ou melhor encaixe), esquemas de desfragmentação (unificação de fatias e

escalonamento alternativo), políticas de remoção da fila de espera (Primeiro a Entrar Primeiro

a ser Servido ou Menor Tarefa Primeiro), níveis de multiprogramação (limitado ou ilimitado).

As formas de empacotamento são as configurações que alocam as tarefas aos EPs. O esquema

de desfragmentação é a forma como as tarefas são redistribuídas entre as fatias de tempo do

escalonador para evitar a fragmentação. Já a política de remoção da fila de espera é composta

pelas regras que o RGSA utiliza para remover as tarefas da fila de espera e colocar em

execução. Por fim, o nível de multiprogramação é a quantidade de fatias de tempo que o

algoritmo utiliza para realizar o escalonamento.

Por fim, a CCC é implementada como uma tabela que sabe, baseada em alguns

parâmetros de entrada que foram citados anteriormente, qual a melhor configuração para a

execução da tarefa atual. Assim, a CCC vai configurando dinamicamente para cada tarefa ou

30

conjunto de tarefas em questão as melhores configurações para aquele escopo atual. A Figura

2 mostra como exemplo uma das configurações possíveis para o RGSA.

Figura 2 - Uma das configurações do RGSA

Fonte: (GÓES; MARTINS, 2004b)

2.5 Principais Trabalhos Relacionados

Na revisão bibliográfica realizada encontramos alguns trabalhos relacionados. Em se

tratando de trabalhos relacionados com escalonadores de tarefas, teremos uma infinidade de

trabalhos correlatos.

Já se formos citar trabalhos sobre escalonadores reconfiguráveis, encontramos um que

possui alguma semelhança. Em (MONTANA; HUSSAIN; VIDAVER, 2007), foi

desenvolvido e proposto o Vishnu, um escalonador reconfigurável baseado em algoritmo

genético para resolver problemas clássicos de escalonamento e não problemas no contexto de

computação e escalonamento de tarefas paralelas. Os problemas resolvidos pelo Vishnu são

Traveling Salesman Problem, Job-Shop Scheduling Problem e Vehicle Routing Problem with

31

Time Windows. Ou seja, não são problemas de escalonamento de tarefas paralelas em sistemas

de computação paralelos.

Com relação à reconfiguração, além do (MONTANA; HUSSAIN; VIDAVER, 2007)

descrito anteriormente, encontramos outro trabalho semelhante ou parecido. Este trabalho é

descrito em (FREITAS et al, 2008) e é aplicado em redes de sensores e utiliza suporte a

reconfiguração para escalonamento de serviços. Apesar de escalonar tarefas, o foco são os

serviços. Com isso, o escalonador descrito em (MONTANA; HUSSAIN; VIDAVER, 2007) é

executado em um sistema de rede de sensores e não em um sistema de computação paralelo.

Outra diferença é que ele escalona tarefas para priorizar os serviços da rede de sensores e não

para questões de desempenho das tarefas que estão sendo executadas.

Encontramos vários trabalhos, como os descritos em (PAN; WELLS, 2008;

CLEMENTE. et AL, 2008), que utilizam reconfiguração em escalonamento de tarefas

utilizando reconfiguração em hardware reconfigurável FPGA e não reconfiguração em

software como no nosso trabalho.

O único escalonador reconfigurável de tarefas paralelas que encontramos foi o RGSA.

E os únicos trabalhos diretamente relacionados com escalonamento reconfigurável de tarefas

paralelas em software foram os ligados à dissertação de mestrado “Proposta e

Desenvolvimento de um Algoritmo Reconfigurável de Escalonamento Paralelo de Tarefas”

(GÓES; MARTINS, 2004b), entre eles (GÓES; MARTINS, 2003; GÓES; MARTINS,

2004a). Além disso, outro trabalho relacionado é a “Técnica de Caracterização de Cargas de

Trabalho de Supercomputadores” descrita em (SANTOS; SILVA; GÓES, 2009) que foi

utilizada para a caracterização das cargas de trabalho do passado para utilizarmos na tomada

de decisão da predição das configurações do RGSA mais indicadas para cada uma das cargas

de trabalho.

32

3 PROPOSTA DE SOLUÇÃO

Neste capítulo apresenta-se a proposta de solução da pesquisa. Inicialmente

detalhamos o contexto referente à proposta de solução. Posteriormente, é feita uma análise do

RGSA originalmente concebido e de sua respectiva camada de controle de configuração

(CCC Original). Ao final detalhamos a proposta de solução com a alteração da CCC do

RGSA e fazemos as considerações finais do capítulo.

3.1 Contexto da Proposta de Solução

Como foi apresentado e justificado anteriormente na introdução, o escalonador

reconfigurável de tarefas paralelas escolhido para ser utilizado nesta pesquisa foi o

Reconfigurable Gang Scheduling Algorithm (RGSA).

O algoritmo original do escalonador reconfigurável de tarefas RGSA possui uma

Camada de Controle de Configuração (CCC) que é a responsável por configurar o

escalonador com a configuração mais indicada para a carga de trabalho. A carga de trabalho é

submetida ao computador paralelo e o RGSA a recebe e a coloca em uma fila de espera. Cada

carga de trabalho precisa estar anotada com algumas informações citadas a seguir para que o

RGSA possa interpretar a informação contida nesta anotação e possa configurar o escalonador

com uma das configurações disponíveis. Para o caso do RGSA, a anotação precisa conter as

seguintes informações, como explicado na seção 2.4:

a) Tempo de execução: alto ou baixo;

b) Grau de paralelismo: alto ou baixo;

c) Grau de predominância: 60%, 80% ou 100%.

De posse dessas informações das anotações da carga, a CCC faz uma avaliação e

configura o RGSA com a configuração mais adequada de escalonamento disponível no

escalonador para a carga.

Pelo fato do RGSA necessitar da anotação da carga para que o escalonador funcione

na prática e assim escalonamento seja realizado, temos duas estratégias possíveis. Uma das

estratégias é a utilização de caracterização explícita e a outra é a utilização de alguma forma

de predição. A primeira estratégia seria o desenvolvimento de um módulo de extração de

33

anotações ou caracterização explícita das cargas. Esse módulo deve fazer a extração das

informações necessárias da carga para que o RGSA se reconfigure com a melhor configuração

para a respectiva carga, assim que a mesma chegar ao computador paralelo. Utilizamos dessa

forma, dados do presente para extrair a anotação. A segunda estratégia é o desenvolvimento

de um mecanismo de predição ou escolha das configurações que não dependa da

etiquetagem/anotação padrão do RGSA para ser incorporado ao algoritmo. Assim, utilizamos

alguma informação do passado para isso.

Com relação à primeira solução, a criação de um módulo de caracterização explícita

ou extração de anotações das cargas de trabalho utilizando dados da carga que acabou de

chegar, não é uma tarefa simples e trivial. Temos uma alta complexidade e um tempo alto de

extração de informações sobre as cargas que chegam ao RGSA para serem executadas. Assim

que a carga chega à fila de espera, este módulo deve extrair informações a respeito da carga

para anotá-la com as informações de que a CCC do RGSA necessita para poder configurá-lo

mais eficientemente. E o ideal é que esta extração e anotação forneçam o resultado

instantaneamente para não gerar sobrecarga no escalonador e para que o escalonador possa

adequar a carga e priorizá-la de acordo com suas características.

Já a segunda solução, um mecanismo de predição ou escolha das configurações, ao

invés da utilização da anotação da carga para poder realizar a escolha da configuração ideal

do RGSA, podemos utilizar outro mecanismo. Este mecanismo pode se basear em

informações extraídas previamente a partir de rastros de execuções passadas da carga. Com

isso, pode-se gerar um preditor que será utilizado como base para realizar o escalonamento.

Portanto, devido ao fato da alta complexidade e do alto tempo para anotar as cargas de

trabalho, optamos pela segunda opção de solução para pesquisarmos e desenvolvermos um

novo mecanismo de predição ou escolha das configurações para o RGSA. Desta forma,

incorporaremos na CCC do RGSA um novo mecanismo preditor das configurações do

escalonador reconfigurável para que as cargas de trabalho possam ser executadas de maneira

rápida e eficiente.

3.2 Análise da Camada de Controle de Configuração Original

Uma das características dos algoritmos reconfiguráveis, em especial o RGSA, que os

tornam eficientes é o seu mecanismo de adaptação às cargas (GÓES; MARTINS, 2004b). Ou

seja, quanto melhor for a predição da configuração ideal ou da configuração mais indicada,

mais eficiente será o algoritmo. E este mecanismo precisa ser bastante eficaz para que os

34

algoritmos em questão possam usufruir de todo o seu potencial. Um mecanismo de predição

de carga ideal deve escolher configurações que sejam eficientes e deve possuir alguma forma

de adaptação ou aprendizado. E devem analisar e levar em consideração o fator overhead para

essas alterações também. Com isso, eles vão alterando as configurações de acordo as

variações das cargas de trabalho de acordo com a necessidade. Pelo fato de nem sempre

possuírem um mecanismo ideal de adaptação às cargas, os algoritmos em questão, em sua

maioria, são implementados em simuladores com algumas simplificações. Por isso,

procuramos pesquisar e propor uma forma de implementar um mecanismo de predição de

configuração para os algoritmos reconfiguráveis de escalonamento paralelo de tarefas.

Nesta pesquisa utilizamos o RGSA pela qualidade dos resultados que ele mostrou

(GÓES; MARTINS, 2004a; GÓES; MARTINS, 2004b) e pelo acesso tanto ao código fonte

do algoritmo do escalonador quanto ao código fonte do ClusterSim, o simulador para o qual

ele foi desenvolvido, os quais são abertos.

Figura 3 - Representação simplificada do RGSA Original

Fonte: Elaborada pelo autor

Uma representação simplificada do escalonador de tarefas paralelas utilizando o

algoritmo RGSA Original é mostrada na Figura 3. O RGSA possui uma Camada de Controle

de Configuração (CCC) que é a parte do algoritmo que tem a função de configurar o

escalonador com as configurações mais adequadas para cada uma das cargas ou sub-cargas

que chegam. A CCC do RGSA Original tem como pré-requisito receber, juntamente com a

tarefa ou conjunto de tarefas, a etiqueta com informações detalhadas desta sub-carga. Com

essa informação, o RGSA Original associa na CCC a(s) tarefa(s) com as configurações mais

indicadas de acordo com as características da(s) mesma(s). E o escalonador vai executando as

35

tarefas com as configurações que a CCC repassa como sendo as melhores para aquela

etiqueta/sub-carga. Contudo, obter antecipadamente informações detalhadas das tarefas para

etiquetá-las não é um trabalho simples e rápido de se realizar antes da execução da carga de

trabalho.

Por isso, nessa pesquisa desenvolvemos uma solução diferente da originalmente

concebida para o RGSA, que não dependa da etiquetagem das cargas. Isso, pois a escolha da

melhor configuração para uma determinada carga é uma tarefa bastante difícil, visto que é um

problema com ordem de complexidade exponencial.

3.3 Proposta de Solução

A proposta de solução é se utilizar uma outra forma ou maneira de classificar a carga

ao invés de utilizar a anotação, ou etiqueta, da carga. Assim, queremos criar um mecanismo

de controle de configurações mais simples, rápido e eficaz de pré-classificar a carga baseada

no momento em que a carga chega à fila de recebimento (fila de espera) do escalonador

RGSA. Com isso, o que queremos é tirar a dependência de algum módulo interno ou externo

ao algoritmo reconfigurável RGSA, o qual seja responsável pela anotação das cargas de

trabalho submetidas ao escalonador.

A proposta de solução desta pesquisa é um controle de configuração para

escalonadores reconfiguráveis de tarefas paralelas que não necessite extrair e analisar dados

da carga de trabalho que está chegando para escalonar eficientemente as suas tarefas. Este

controle está sendo proposto inicialmente para o RGSA com a alteração da camada de

controle de configuração (CCC) do RGSA Original, mas pode ser implementado em outros

escalonadores reconfiguráveis de tarefas paralelas futuramente. Com essa alteração, a CCC

não necessitará mais que as cargas de trabalho submetidas estejam anotadas para escalonar as

tarefas. Assim, como mostrado na Figura 4, o que queremos é introduzir na CCC Original um

método Preditor, que não precise receber a anotação das cargas de trabalho submetidas.

36

Figura 4 - Proposta de solução para a CCC do RGSA - RGSA com CCC Proposta

RGSA

Tarefa 1Escalonador Paralelo

de Tarefas

Computador Paralelo

Fila de

Recebimento

de Tarefas

Tarefa N...

CCC com

PREDITOR

Configuração


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


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


A Fase de Predição das configurações é mostrada na 1ª parte do fluxo da Figura 7. No

item 1 extraímos os dados analíticos referentes aos N períodos de cargas de trabalho

submetidas ao computador paralelo. No item 2, de posse desses dados descritos no item 1,

geramos cargas sintéticas com o agrupamento desses N períodos subdividindo-os em

intervalos utilizando modelagem estatística e levando em consideração a média dos dados dos

N períodos em questão. A etapa do item 2 é gerada utilizando a técnica de caracterização de

cargas de trabalho descrita em (SANTOS; SILVA; GÓES, 2009). Com isso, geramos a carga

sintética do item 3. Então, já no item 4, executamos esta carga sintética com cada uma das Y

configurações fixas disponíveis no RGSA mostradas no Quadro 2 e para cada um dos X

intervalos do período. Após isso, no item 5, geramos a configuração para a CCC Proposta do

RGSA para cada intervalo do período como sendo uma tabela contendo o intervalo do período

e a configuração mais indicada para o determinado intervalo assim como mostrado no Quadro

3. O exemplo abaixo retrata um período de 1 semana e o intervalo em horas da semana.

42

Quadro 3 - Exemplo de tabela de configurações da nova CCC Proposta para o RGSA

com intervalos em horas da semana e período de 1 semana

Hora da Semana Melhor Configuração

0 Configuração 05

1 Configuração 01

2 Configuração 12

3 Configuração 08

... ...

166 Configuração 11

167 Configuração 11 Fonte: Elaborada pelo autor

Na 2ª parte do fluxo da Figura 7, temos a Fase de Execução. No item 6, extraímos os

dados relacionados ao instante de submissão de cada tarefa referentes ao primeiro período

posterior da carga de trabalho do item 1. Já no item 7, executamos esta carga do item 6 no

RGSA, com a CCC Proposta carregada com as configurações mais indicadas que foram

geradas na Fase de Predição no item 5. Sendo que essa execução do item 7 com o RGSA com

a CCC Proposta vai sendo reconfigurada dinamicamente entre as Y configurações do item 8 a

cada intervalo do período utilizado de acordo com os dados da CCC Proposta. Contudo,

precisamos alterar a forma de reconfiguração do RGSA para que a utilização da CCC

Proposta seja possível. O RGSA originalmente concebido tinha a reconfiguração realizada de

acordo com as anotações recebidas juntamente com as cargas ou sub-cargas de trabalho.

Assim, incorporamos no RGSA com a CCC Proposta, um mecanismo de alteração das

configurações da camada CCC Proposta para que as alterações sejam realizadas a cada

intervalo do período utilizado, de acordo com as informações que a CCC Proposta recebeu da

Fase de Predição das configurações.

Assim, queremos mostrar que a predição das configurações mais indicadas para cada

intervalo do período em questão utilizando agrupamento e modelagem estatística

fundamentada na execução anterior das cargas de trabalho é uma boa alternativa para auxiliar

nas tomadas de decisão do escalonador. Além disso, é uma maneira de implementar a CCC do

RGSA na prática de uma forma simples. Queremos mostrar, também, que a perda de

desempenho é a menor possível levando em consideração as características ideais que a CCC

do RGSA Original utiliza.

43

3.4 Considerações Finais

A nossa proposta de um controle de configuração para escalonadores reconfiguráveis

de tarefas paralelas apresentada para a CCC do RGSA utiliza predição das configurações

fundamentada no agrupamento e modelagem estatística das cargas de trabalho executadas no

passado para tomar as decisões. Este controle pode utilizar inúmeras variações para os

parâmetros como período e intervalos de tempo do período.

A nossa hipótese é que a CCC Proposta pode trazer ganhos de desempenho,

principalmente nos casos em que não sabemos que tipo de configurações o escalonador deve

possuir ou utilizar. Com a utilização de diversas configurações por meio de reconfigurações

feitas pelo algoritmo do RGSA a cada intervalo de tempo de um período, podemos ter ganhos

significativos. Isso, pois a predição das configurações do RGSA com a CCC Proposta é feita

com o intuito de utilizar as melhores configurações a cada intervalo do período. Além disso,

podemos introduzir novas opções de configuração no escalonador caso as configurações não

estejam atendendo às expectativas ou às características das cargas de trabalho.

44

4 RESULTADOS

Neste capítulo apresentam-se os resultados da pesquisa. Inicialmente apresentamos o

ambiente de experimentação, com as cargas de trabalho utilizadas, uma análise comparativa

destas cargas utilizadas na Fase de Predição, a configuração dos experimentos e os recursos

computacionais utilizados. Posteriormente apresentamos os resultados da Fase de Predição

das configurações, os resultados da Fase de Execução (operação) da carga, a análise dos

resultados e ao final, as considerações finais do capítulo.

4.1 Ambiente de Experimentação

Nesta pesquisa, sentimos a necessidade de utilizar cargas de trabalho reais para

verificação e validação do RGSA com a CCC Proposta visto que o RGSA não havia sido

testado, até o momento, com cargas reais. Queríamos que estas cargas possuíssem

características diferentes entre si, como descrito com mais detalhes no item 4.1.1. Com isso,

podemos testar o RGSA com a CCC Proposta em diferentes cenários. Assim, apesar de

utilizarmos simulação para testar a proposta de solução, queremos ficar mais próximos da

realidade com essa decisão de utilizar rastros de cargas reais executadas em sistemas de

computação paralelos reais.

Nos subitens desta seção 4.1, apresentamos inicialmente com maiores detalhes as

cargas de trabalho utilizadas, uma análise comparativa destas cargas utilizadas para

realizarmos o agrupamento e a modelagem estatística na Fase de Predição das configurações

do RGSA, a configuração dos experimentos e ao final os recursos computacionais utilizados

nas simulações.

4.1.1 Cargas de Trabalho

As cargas de trabalho que utilizamos nesta pesquisa foram obtidas de sistemas de

computação paralelos reais utilizados em produção e disponibilizadas no site

http://www.cs.huji.ac.il/labs/parallel/workload/logs.html (EXPERIMENTAL SYSTEMS

LAB, 2008). Estas cargas estão disponibilizadas em arquivos no formato .SWF (Standard

Workload Format) (THE STANDARD WORKLOAD FORMAT, 2011) os quais representam

45

logs brutos das tarefas executadas em sistemas de computação reais. Escolhemos três cargas

com características diferentes entre si para a pesquisa, que estão descritas a seguir:

a) The High Performance Computing Center North (HPC2N) Log – Log extraído do

Cluster Linux chamado Seth do High Performance Computing Center North na

Suécia. O rastro contém 527.371 tarefas executadas entre julho de 2002 e janeiro

de 2006. O Cluster Seth possui 120 nodos, cada um possuindo 2 processadores

modelo 240 AMD Athlon MP2000+ com freqüência de 1.667GHz e 1GB RAM. A

interconexão é feita por placas 3D SCI (Scalable Coherent Interface) organizadas

como grade 4x5x6 e utilizando também uma rede Fast Ethernet. O escalonador

utilizado é o Maui (MAUI CLUSTER SCHEDULER, 2011) e o desempenho total

chega a 800 Gflops. Deste rastro utilizamos o mês de Maio/2003 para a

modelagem estatística da carga de trabalho e a primeira semana de Junho/2003

para a execução dos testes de verificação;

b) The Los Alamos National Lab (LANL) CM-5 Log – Log extraído do cluster do

laboratório Los Alamos National Lab nos EUA (LOS ALAMOS NATIONAL

LAB, 2011), um sistema com 1024 nodos Connection Machine CM-5 com pelo

menos 32 processadores cada. O rastro contém 201.387 tarefas executadas entre

outubro 1994 e setembro de 1996. O escalonamento é realizado pelo software DJM

(Distributed Job Manager). Deste rastro utilizamos o mês de Setembro/1995 para

a modelagem estatística e a primeira semana de Outubro/1995 para a execução dos

testes de verificação;

c) The San Diego Supercomputer Center (SDSC) DataStar Log – Log extraído do

Cluster com 184 nodos IBM sendo 176 nodos p655 (com 8 processadores SMP

com freqüência de 1.5 GHz e 16GB RAM por nodo), e 8 nodos p690 (com 32

processadores SMP com freqüência de 1.7 GHz e 128 GB RAM ou 64 GB RAM

por nodo). Este Cluster é da Universidade da Califórnia em San Diego, EUA. O

co-escalonamento utilizado é o GUR (Grid Universal Remote). O rastro contém

96.089 tarefas executadas entre março de 2004 e março de 2005. Deste rastro

utilizamos o mês de Setembro/2004 para a modelagem estatística e a primeira

semana de Outubro/2004 para a execução dos testes de verificação.

Os arquivos obtidos no site citado estão no formato .SWF bruto como mostrado na

Figura 8. Cada linha do arquivo representa uma tarefa e suas características. Cada coluna

46

representa uma informação sobre a tarefa descrita em (THE STANDARD WORKLOAD

FORMAT, 2011). Foram utilizadas somente três colunas dos arquivos. Elas são a segunda, a

quarta e a quinta, conforme mostrado no exemplo a seguir, devido às características e

simplificações do simulador e da pesquisa. Estas três colunas representam, respectivamente,

tempo de submissão, tempo de execução e o número de processos.

Figura 8 - Parte do arquivo .SWF referente à carga HPC2N 1 0 308434 31405 30 31405 -1 30 37980 -1 1 1 1 -1 -1 1 -1 -1

2 8 308426 31039 30 31039 -1 30 37980 -1 1 1 1 -1 -1 1 -1 -1

3 12 308483 30978 30 30978 -1 30 37980 -1 1 1 1 -1 -1 1 -1 -1

4 179350 99808 143967 2 142977 -1 2 144000 -1 1 3 1 -1 -1 1 -1 -1

10 310085 29510 2326 40 2326 -1 40 43200 -1 1 4 1 -1 -1 1 -1 -1

11 342072 32 43306 32 43307 -1 32 43200 -1 1 4 1 -1 -1 1 -1 -1

12 342343 5 553 40 552.21 -1 40 43200 -1 1 4 1 -1 -1 1 -1 -1

13 342921 102 10027 40 10027 -1 40 43200 -1 1 4 1 -1 -1 1 -1 -1

14 347226 15 33156 8 33157 -1 8 86400 -1 1 5 1 -1 -1 1 -1 -1

15 347593 15 86462 8 86464 -1 8 86400 -1 1 5 1 -1 -1 1 -1 -1


Com as três colunas utilizadas dos arquivos no formato .SWF (segunda, quarta e

quinta colunas do arquivo original), criamos os arquivos no formato .LOG para serem

utilizados no ClusterSim. Num arquivo no formato .LOG, cada linha representa uma tarefa e

as colunas (separadas pelo caractere de tabulação) representam informações desta tarefa sendo

a primeira coluna o tempo de submissão, a segunda o tempo de execução da tarefa e a terceira

o número de processos da tarefa. Um exemplo de arquivo .LOG é mostrado na Figura 9.

Figura 9 - Parte do arquivo .LOG referente à carga HPC2N mostrada na Figura 8 0 31405 30

8 31039 30

12 30978 30

179350 143967 2

310085 2326 40

342072 43306 32

342343 553 40

342921 10027 40

347226 33156 8

347593 86462 8


O ClusterSim possui os modos de execução probabilístico e determinístico. O modo

probabilístico utiliza percentuais para representar uma carga com as respectivas tarefas e seus

47

processos baseado em um determinado intervalo ou período de tempo. Já no modo

determinístico, utilizamos os dados diretos de cada tarefa e seus respectivos processos, ou

seja, o rastro de uma determinada carga de trabalho.

Utilizando o modo probabilístico faremos a Fase de Predição das configurações da

carga utilizando agrupamento e modelagem estatística para gerar a CCC Proposta conforme

mostrado na Figura 10.

Figura 10 - Fluxo de geração da CCC Proposta na Fase de Predição (modo

probabilístico utilizando agrupamento e modelagem estatística) para carga de

Janeiro/2000

Fonte: Elaborado pelo autor

Na Figura 10, a partir da carga bruta do período de Janeiro/2000 mostrada no item 1, e

realizando o agrupamento e a modelagem estatística mostrados no item 2, geramos dados

sintéticos, utilizando a Técnica de Caracterização de Cargas de Trabalho (SANTOS; SILVA;

GÓES, 2009). Estes dados sintéticos são gerados no formato de arquivos workload (.WKL)

conforme mostrado anteriormente no exemplo da Figura 6. Para esta pesquisa, os arquivos

.WKL foram gerados a partir de arquivos .LOG contendo tarefas e processos de um mês

completo. Estes dados de um mês (N períodos) foram sintetizados com agrupamento em horas

de uma semana (intervalos do período) utilizando modelagem estatística para o cálculo das

médias aritméticas.

Assim, para a Fase de Predição utilizando modelagem estatística da carga de trabalho,

para gerarmos a CCC Proposta, configuramos o ClusterSim para o modo de execução

probabilístico utilizando estes arquivos .WKL gerados. Posteriormente, na Fase de Execução

mostrada na Figura 11, testamos a eficiência do RGSA com a CCC Proposta. Para isso,

configuramos o ClusterSim para o modo determinístico e executamos arquivos .LOG da

48

semana posterior aos dados utilizados para realizarmos a predição utilizando modelagem

estatística. Nesta Fase de Execução, conforme mostrado na Figura 11, a carga bruta do item 6

é executada no item 7 pelo RGSA com a CCC Proposta, onde a CCC Proposta vai

reconfigurando dinamicamente o RGSA com as configurações preditas na Fase de Predição.

As configurações disponíveis são mostradas no item 8.

Figura 11 - Fase de Execução (modo determinístico) para carga de Fevereiro/2000

Fase de Execução

Escolha das Configurações pelo

RGSA Proposto a cada hora

6.Carga Bruta

1a semana de

Fevereiro de 2000

8.Execução da

Carga Bruta 6 -

Configuração 12

...

7.Execução da

Carga Bruta 6 –

RGSA Proposto

8.Execução da

Carga Bruta 6 -

Configuração 1


Para fazermos a verificação do RGSA com a CCC Proposta, precisamos realizar testes

com as 12 configurações fixas conforme mostrado na Figura 12 utilizando dados da carga da

semana posterior aos dados (carga bruta do item 6 da Fase de Execução) utilizados para a

predição das configurações. Com isso podemos comparar o RGSA com a CCC Proposta com

relação às 12 diferentes opções de configuração disponíveis no RGSA, como mostrado no

Quadro 2.

49

Figura 12 - Estrutura de testes de verificação do RGSA com a CCC Proposta

Geração de Dados para

Comparação

Estrutura de testes de verificação

na Fase de Execução

9.Execução da

Carga Bruta 6 -

Configuração 1

9.Execução da

Carga Bruta 6 -

Configuração 12

...


4.1.2 Análise Comparativa das Cargas de Trabalho Utilizadas na Fase de Predição

A seguir, analisamos com detalhes as características das cargas de trabalho obtidas

com o agrupamento e a modelagem estatística que foram utilizadas na Fase de Predição das

configurações. A Tabela 1 a seguir nos mostra algumas informações referentes às cargas de

trabalho utilizadas nesta pesquisa. Os dados são referentes aos valores das médias aritméticas

extraídas das cargas por hora da semana. Devemos ressaltar que as cargas foram simuladas

considerando um cluster com 512 elementos de processamento. Este valor foi determinado

devido ao número máximo de processos por tarefa ser 512 de acordo com os logs das cargas

de trabalho utilizadas nesta pesquisa. E que o tempo de execução máximo por hora é 3.600

segundos para garantirmos que as tarefas se iniciam e terminam dentro da mesma hora e não

invadem a hora seguinte. Desta forma não atrapalhamos a predição das configurações

comprometendo o intervalo do período seguinte com tarefas do intervalo atual ou anterior.

Mas para conseguirmos isso, tivemos que partir as tarefas que invadiam horas diferentes e

colocar cada pedaço no intervalo (hora da semana) em que é executada.

50

Tabela 1 - Médias por hora referentes às características das cargas utilizadas na Fase de

Predição

Carga utilizada na

Predição (Amostra de

1 mês)

HH ( % )

HL ( % )

LL ( % )

LH ( % )

Num Jobs

Min Deg

Med Deg

Max Deg

Min Time (seg)

Med Time (seg)

Max Time (seg)

HPC2N 14,83 5,36 24,07 55,74 62 1 5 64 1 2.688 3.600 LANLCM5 21,75 17,90 31,48 28,87 14 32 124 512 1 1.659 3.600 SDSC 18,78 12,38 26,87 41,97 33 8 52 512 1 2.398 3.600

* Legenda: HH - alto nível de paralelismo - alto tempo de execução; HL - alto nível de paralelismo - baixo tempo de execução; LL - baixo nível de paralelismo - baixo tempo de execução; LH - baixo nível de paralelismo - alto tempo de execução; Num Jobs (Number of Jobs) - Número de tarefas submetidas; Min Deg (Minimum Degree) - Número mínimo de processos; Med Deg (Medium Degree) - Número médio de processos; Max Deg (Maximum Degree) - Número máximo de processos; Min Time (Minimum Time) - Tempo de execução mínimo; Med Time (Medium Time) - Tempo de execução médio; Max Time (Maximum Time) - Tempo de execução máximo.


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


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 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


Para a carga LANLCM5, podemos observar no Gráfico 2 que a configuração da CCC

Proposta do RGSA utilizou 7/12 das configurações e durante alguns horários seguidos da

58

semana foi constante. No geral não sofreu muitas reconfigurações e concentrou a maior parte

do tempo nas Configurações 02, 04, 06 e 08.

Tabela 3 - Configurações utilizadas nos resultados da carga LANLCM5 - Fase de

Predição

Configuração Quantidade Percentual Utilizado (%)

Configuração 01 4 2,38 Configuração 02 32 19,05 Configuração 03 1 0,60 Configuração 04 31 18,45 Configuração 05 0 0,00 Configuração 06 59 35,12 Configuração 07 0 0,00 Configuração 08 33 19,64 Configuração 09 0 0,00 Configuração 10 8 4,76 Configuração 11 0 0,00 Configuração 12 0 0,00



configurações da CCC Proposta do RGSA para a carga LANLCM5, na qual 58,33% das

configurações disponíveis foram utilizadas.

59

Gráfico 3 - Preditor gerado para a Carga SDSC


Já para a carga SDSC, observamos que a configuração da CCC Proposta do RGSA

utilizou 2/3 das configurações disponíveis e teve muitas reconfigurações conforme mostrado

no Gráfico 3. Porém, concentrou mais da metade do tempo na Configuração 06.

Tabela 4 - Configurações utilizadas nos resultados da carga SDSC - Fase de Predição

Configuraçãoo Quantidade Percentual Utilizado (%)

Configuração 01 3 1,79 Configuração 02 8 4,76 Configuração 03 5 2,98 Configuração 04 19 11,31 Configuração 05 0 0,00 Configuração 06 101 60,12 Configuração 07 0 0,00 Configuração 08 6 3,57 Configuração 09 3 1,79 Configuração 10 23 13,69 Configuração 11 0 0,00 Configuração 12 0 0,00


60


configurações da CCC Proposta do RGSA para a carga SDSC, na qual 66,67% das

configurações disponíveis foram utilizadas.

Comparando a Fase de Predição para as 3 cargas de trabalho utilizadas, apenas uma

das cargas, a HPC2N, não sofreu nenhuma reconfiguração dentre as 168 reconfigurações que

as cargas poderiam realizar durante o período utilizado de uma semana. Já a carga LANLCM5

sofreu 47 reconfigurações e a SDSC 80 reconfigurações.

4.3 Fase de Execução (Operação)

Os resultados seguintes referem-se à Fase de Execução (ou Operação) do RGSA com

a CCC Proposta, que foi implementada no ClusterSim. Para este modo, utilizamos as 12

configurações fixas disponíveis no RGSA e o próprio RGSA utilizando a CCC Proposta.

Nesta fase, executamos as 3 cargas de trabalho que estão em formato de arquivo .LOG, as

quais são referentes ao período posterior ao utilizado na Fase de Predição. Ou seja, fizemos a

predição com cargas de um mês (N períodos) e montamos a CCC Proposta. Depois,

executamos as mesmas 3 cargas porém de períodos futuros (primeira semana do mês

seguinte) com o RGSA utilizando a CCC Proposta. Após isso, executamos estas mesmas

cargas futuras com as 12 configurações fixas do RGSA para comparações e análises.

4.3.1. Fase de Execução com a Carga HPC2N

Comparando-se a execução da carga HPC2N com as 12 configurações fixas utilizadas

pelo RGSA e o RGSA com a CCC Proposta, observa-se que o RGSA com a CCC Proposta

obteve o segundo melhor tempo de execução. A diferença absoluta entre os valores mínimo

(802.700 segundos) e máximo (1.001.300 segundos) foi de 198.600 segundos. O que

corresponde a 24,74% em relação ao mínimo e 19,83% em relação ao máximo, conforme

dados da Tabela 5.

61

Gráfico 4 - Tempo de execução para a carga HPC2N


Neste caso específico da carga HPC2N, o RGSA com a CCC Proposta foi montado

utilizando-se apenas a Configuração 02 sem ter reconfiguração (ou seja, não se gastou tempo

com a reconfiguração do RGSA). Isso explica porque o RGSA com a CCC Proposta obteve o

mesmo tempo de execução da Configuração 02, visto que o RGSA com a CCC Proposta ficou

fixo nesta configuração.

Comparando as duas fases do RGSA com a CCC Proposta, percebemos que a Fase de

Predição das configurações gerou como resultado a Configuração 02 e a Fase de Execução

mostrou que a Configuração 05 foi a melhor. Isso mostra um erro da Fase de Predição do

RGSA. Já se compararmos os tempos de execução do RGSA com a CCC Proposta e o melhor

tempo dentre as configurações fixas, a perda de desempenho foi de 0,19% no tempo. E se

fizermos a mesma comparação do RGSA com a CCC Proposta com o pior tempo obtido,

tivemos um ganho de 24,51% com relação ao tempo de execução. Os valores podem ser

visualizados na Tabela 5 mostrada a seguir.

62

Tabela 5 - Tempo de execução HPC2N - RGSA com a CCC Proposta em relação às 12

configurações fixas

Configuração Tempo de Execução (s) Ganho RGSA com a CCC Proposta (%)

RGSA com a CCC Proposta 804.200 - Configuração 01 831.440 3,39 Configuração 02 804.200 0,00 Configuração 03 812.280 1,00 Configuração 04 804.200 0,00 Configuração 05 802.700 -0,19 Configuração 06 804.200 0,00 Configuração 07 1.001.300 24,51 Configuração 08 851.000 5,82 Configuração 09 1.001.300 24,51 Configuração 10 851.000 5,82 Configuração 11 1.001.300 24,51 Configuração 12 851.000 5,82


Vale ressaltar que o cluster simulado na pesquisa (que possui 512 elementos de

processamento) foi pouco utilizado para a carga HPC2N, visto que a quantidade média de

tarefas disparadas foi de 62 e a quantidade máxima de processos disparados por tarefa por

hora foi de 64 conforme mostra a Tabela 1. Assim, não foi necessário ser reconfigurado pela

CCC Proposta do escalonador RGSA.

4.3.2. Fase de Execução com a Carga LANLCM5

Comparando as 12 configurações fixas e o RGSA com a CCC Proposta, o RGSA com

a CCC Proposta executando a carga LANLCM5 obteve o quinto melhor tempo de execução.

A diferença absoluta entre os valores mínimo (905.540 segundos) e máximo (1.095.760

segundos) foi de 190.220 segundos. O que corresponde a 21,01% em relação ao mínimo e

17,36% em relação ao máximo, conforme dados da Tabela 6.

63

Gráfico 5 - Tempo de execução para a carga LANLCM5


Neste caso da carga LANLCM5, o RGSA com a CCC Proposta foi montado utilizando

7 das 12 configurações possíveis para o RGSA, utilizadas nesta pesquisa. Se comparados os

tempos do RGSA com a CCC Proposta e o melhor tempo, a perda foi de 4,04% no tempo. E

se compararmos o RGSA com a CCC Proposta e o pior tempo, tivemos um ganho de

desempenho de 16,11% com relação ao tempo de execução. Os ganhos podem ser


64

Tabela 6 - Tempo de execução LANLCM5 - RGSA com a CCC Proposta em relação às

12 configurações fixas

Configuração Tempo de Execução (s) Ganho RGSA com a CCC Proposta (%) RGSA com a CCC Proposta 943.700 - Configuração 01 1.044.740 10,71 Configuração 02 1.025.280 8,64 Configuração 03 964.060 2,16 Configuração 04 905.540 -4,04 Configuração 05 959.200 1,64 Configuração 06 939.400 -0,46 Configuração 07 1.095.760 16,11 Configuração 08 1.083.320 14,79 Configuração 09 927.300 -1,74 Configuração 10 919.500 -2,56 Configuração 11 1.031.980 9,35 Configuração 12 952.400 0,92


4.3.3. Fase de Execução com a Carga SDSC

Comparando as 12 configurações fixas e o RGSA com a CCC Proposta, o RGSA com

a CCC Proposta executando a carga SDSC obteve o sétimo melhor tempo de execução. E

apesar disso, ele foi apenas 5,78% pior em termos de desempenho que o melhor caso. A

diferença absoluta entre os valores mínimo (1.403.300 segundos) e máximo (2.930.300

segundos) foi de 1.527.000 segundos. O que corresponde a 108,81% em relação ao mínimo e

52,11% em relação ao máximo, conforme dados da Tabela 7.

65

Gráfico 6 - Tempo de execução para a carga SDSC


Neste caso da carga SDSC, o RGSA com a CCC Proposta foi montado utilizando 8

das 12 configurações possíveis para o RGSA, utilizadas nesta pesquisa. Se comparados os

tempos do RGSA com a CCC Proposta e o melhor tempo, a perda foi de 5,78% no tempo de

execução. E se compararmos o RGSA com a CCC Proposta com o pior tempo, obtivemos um

ganho de desempenho de 96,74% com relação ao tempo de execução. Os valores podem ser


66

Tabela 7 - Tempo de execução SDSC - RGSA com a CCC Proposta em relação às 12

configurações fixas

Configuração Tempo de Execução (s) Ganho RGSA com a CCC Proposta (%)

RGSA com a CCC Proposta 1.489.420 - Configuração 01 1.887.240 26,71 Configuração 02 2.000.740 34,33 Configuração 03 1.467.180 -1,49 Configuração 04 1.486.960 -0,17 Configuração 05 1.487.680 -0,12 Configuração 06 1.403.300 -5,78 Configuração 07 2.930.300 96,74 Configuração 08 2.042.180 37,11 Configuração 09 1.495.740 0,42 Configuração 10 1.484.840 -0,31 Configuração 11 1.633.120 9,65 Configuração 12 1.452.380 -2,49


4.4 Análise dos Resultados

Após estes testes, onde analisamos a execução das 3 cargas de trabalho reais utilizadas

nesta pesquisa com as 12 configurações fixas disponíveis e com o RGSA com a CCC

Proposta, queríamos compará-lo com o melhor caso possível do RGSA com a CCC Proposta.

Ou seja, queríamos comparar os resultados obtidos nesta pesquisa com os resultados do

RGSA com a CCC Proposta Ideal ou Ótima (RGSA com a CCC Proposta que utiliza as

configurações ideais ou ótimas da CCC Proposta para cada hora da semana para a carga). Para

com isso mostrar a perda de desempenho do RGSA com a CCC Proposta em relação ao

RGSA com a CCC Proposta Ideal ou, simplesmente, RGSA Ideal.

O RGSA Ideal é a melhor configuração do RGSA com a CCC Proposta possível para

a carga utilizada. Porém, a dificuldade encontrada é que a resolução desse problema é um

problema com ordem de complexidade exponencial, conforme mostrado na Figura 13. Como

temos 12 configurações fixas de escalonamento diferentes que podem ser utilizados em cada

um dos 168 intervalos de hora do nosso período semanal, o RGSA Ideal tem como esforço 12

^ 168 combinações para se chegar ao resultado. Como as opções de configuração ou

escalonamento são muitas, decidimos utilizar uma aproximação que tivesse um esforço menor

para atingirmos o resultado.

Chamaremos de RGSA Aproximado o algoritmo montado que se baseará na execução

das tarefas disparadas por intervalo de hora. Utilizaremos as mesmas cargas de trabalho da

67

Fase de Execução do RGSA com a CCC Proposta. Primeiramente, executamos cada carga de

trabalho citada com as 12 configurações fixas disponíveis no RGSA com a CCC Proposta e

extraímos os resultados. Após isso, separamos as tarefas dessa carga por hora da semana em

que foram disparadas e por configuração fixa utilizada. De posse das informações das tarefas

separadas por hora da semana e por configuração fixa, escolhemos como a melhor

configuração para determinada hora da semana aquela em que todas as tarefas disparadas

nessa mesma hora finalizarem primeiro. Ao final, montamos a CCC utilizando estas

configurações extraídas para cada hora da semana e executamos a carga de trabalho com o

RGSA Aproximado. Para tal, o esforço será da multiplicação de 12 (número de opções de

configurações fixas diferentes) por 168 (quantidade de intervalos de hora da semana). Isso,

pois com apenas uma execução da carga de trabalho para cada uma das 12 configurações fixas

de escalonamento conseguiremos chegar ao resultado da aproximação desejada.

Figura 13 - Comparação de esforço para calcular RGSA Ideal e Aproximado

RGSA Ideal: esforço de 12 ^ 168

RGSA Aproximado: esforço de 12 x 168

Considerando que 10 x 12 x 168 ~= 12 ^ 4, ou seja, 20.160 ~= 20.736 então:

12 ^ 168 ~= 12 ^ 164 x 12 ^ 4

12 ^ 168 ~= 12 ^ 164 x 10 x 12 x 168

Esforço RGSA Ideal ~= 10 x 12 ^ 164 vezes maior que o RGSA Aproximado


Nosso principal problema foi que as tarefas disparadas em uma determinada hora não

terminam necessariamente na mesma hora. Na Fase de Predição isso acontece porque

dividimos as tarefas em partes de no máximo 1 hora (3.600 segundos) cada e garantimos que

todas as tarefas se iniciam no início de cada hora. Com isso as tarefas não invadem outras

horas. Já na Fase de Execução utilizando as cargas reais, as tarefas iniciam-se em tempos

diferentes. Além disso, podem iniciar em uma determinada hora e terminar em outra hora

subseqüente. Isto acarreta em atraso na execução dos processos das tarefas. Desde modo, o

tempo de execução total da carga referente a 1 semana completa na simulação pode ser

superior a 1 semana (60 segundos x 60 minutos x 24 horas x 7 dias = 604.800 segundos).

Assim, quando definimos que uma configuração é melhor em determinada hora, não

podemos garantir que ela é realmente a melhor baseando-se nessa heurística ou aproximação.

Pois se houverem processos de outras horas sendo executados simultaneamente, não podemos

68

garantir que as configurações que estiverem ativas na CCC do RGSA naquele momento são

as melhores. Essa foi a aproximação utilizada, uma heurística de aproximação das melhores

configurações para cada intervalo de hora do período de uma semana com um esforço 10 x 12

^ 164 vezes menor que o do RGSA Ideal. E essa aproximação demonstrou ser melhor que o

RGSA utilizando a CCC Proposta em 1 das 3 cargas de trabalho reais utilizadas. A seguir

apresentamos os resultados da comparação entre os tempos de execução utilizando as

configurações de escalonamento fixas, o RGSA com a CCC Proposta e o RGSA Aproximado.

Gráfico 7 - Comparativo dos tempos de execução para a carga HPC2N (melhor tempo,

pior tempo, RGSA com a CCC Proposta e RGSA Aproximado)


O Gráfico 7 acima mostra os principais tempos de execução para a carga HPC2N. O

melhor tempo foi utilizando a Configuração 05, o pior tempo foi quando o escalonador

utilizou a Configuração 07. O RGSA com a CCC Proposta teve seu tempo de execução 0,19%

pior que o da melhor configuração (Configuração 05). Além disso, o RGSA com a CCC

Proposta não utilizou reconfiguração (utilizou apenas a Configuração 02). Já o RGSA

Aproximado foi 5,7% pior em termos de desempenho (tempo de execução) do que o RGSA

com a CCC Proposta.

69

Gráfico 8 - Comparativo dos tempos de execução para a carga LANLCM5 (melhor

tempo, pior tempo, RGSA com a CCC Proposta e RGSA Aproximado)


Para a carga LANLCM5, o Gráfico 8 acima nos mostra os principais tempos de

execução que iremos comparar. O melhor tempo foi utilizando a Configuração 04 e o pior

tempo foi quando o escalonador utilizou a Configuração 07. Assim como aconteceu para a

carga HPC2N mostrada anteriormente, a aproximação utilizada para o RGSA Aproximado foi

pior em termos de desempenho (tempo de execução) do que o RGSA com a CCC Proposta. O

percentual neste caso foi 3,84% pior.

70

Gráfico 9 - Comparativo dos tempos de execução para a carga SDSC (melhor tempo,

pior tempo, RGSA com a CCC Proposta e RGSA Aproximado)


Já o Gráfico 9 acima mostra os principais tempos de execução para a carga SDSC. O

melhor tempo foi utilizando a Configuração 06 e o pior tempo foi quando o escalonador

utilizou a Configuração 07. Para esta carga de trabalho, a aproximação utilizada para o RGSA

Aproximado foi 2,62% melhor em termos de desempenho (tempo de execução) do que o

RGSA com a CCC Proposta.

Conforme os tempos de execução mostrados nos 3 primeiros gráficos desta seção 4.4;

Gráfico 7, Gráfico 8 e Gráfico 9; a Configuração 07 obteve o pior tempo de execução para as

3 cargas de trabalho. E o RGSA Aproximado obteve sucesso em 1 das 3 cargas de trabalho

utilizadas.

O esperado era que o RGSA com a CCC Proposta tivesse os melhores resultados em

comparação com as configurações fixas. Mas algumas simplificações utilizadas na pesquisa

podem explicar esse fato e citamos 3 como as principais. O erro ou qualidade da

caracterização da carga de trabalho utilizada na Fase de Predição é uma das simplificações

utilizadas, a qual gera um erro na própria predição que irá se propagar na Fase de Execução.

O intervalo em horas utilizado é outra simplificação que afeta. Ou seja, os parâmetros

utilizados para período e intervalo podem ter impactado diretamente nos resultados. Assim,

um intervalo menor, de 30 minutos ou 15 minutos, por exemplo, deve ser investigado

futuramente para uma melhor compreensão do impacto desse parâmetro. Por último, a

simplificação do RGSA com a CCC Proposta em relação ao RGSA com a CCC Proposta

71

Ideal (que utiliza as melhores configurações e que é um problema com ordem de

complexidade exponencial).

Assim, essas 3 simplificações citadas podem ter seus erros de precisão multiplicados e

podem ter gerado os resultados apresentados na pesquisa. Um exemplo claro disso foram os

resultados encontrados para a carga HPC2N. Na Fase de Predição, a Configuração 02 foi a

melhor configuração encontrada e na Fase de Execução foi mostrado que a Configuração 05

foi a melhor. Apesar de não conseguirmos comprovar essa hipótese, conseguimos mostrar que

ela foi bem próxima dos melhores casos, nunca se mostrando o pior caso.

Nos nossos exemplos de cargas de trabalho, se tivéssemos escolhido aleatoriamente e

sem nenhum critério uma determinada configuração fixa, e esta configuração fosse a pior para

a carga de trabalho, teríamos uma perda de até 16,11 % no melhor caso e uma perda de

96,74% no pior caso, se comparado com o RGSA com a CCC Proposta. E caso

escolhêssemos a melhor configuração fixa aleatoriamente e sem nenhum critério, podíamos

ter obtido um ganho de 0,19% no melhor caso e um ganho de 6,14% no pior caso, se

comparado ao RGSA com a CCC Proposta. Com isso, o que queríamos mostrar é que a

predição das configurações utilizando agrupamento e modelagem estatística fundamentada na

execução de cargas de trabalho do passado é bastante útil. Principalmente quando não

sabemos à priori as características da carga de trabalho a serem executadas ou quando não

dispomos de tempo suficiente para analisá-las imediatamente antes de executá-las.

72

Tabela 8 - Dados comparativos das cargas de trabalho contendo as médias das

características por hora utilizadas na Predição, obtidas com modelagem estatística, e

Execução

Carga utilizada na

Predição (Amostra de

1 mês)

HH ( % )

HL ( % )

LL ( % )

LH ( % )

Num Jobs

Min Deg

Med Deg

Max Deg

Min Time (seg)

Med Time (seg)

Max Time (seg)

HPC2N 14,83 5,36 24,07 55,74 62 1 5 64 1 2.688 3.600 LANLCM5 21,75 17,90 31,48 28,87 14 32 124 512 1 1.659 3.600 SDSC 18,78 12,38 26,87 41,97 33 8 52 512 1 2.398 3.600

Carga

utilizada na Execução

(Amostra de 1 semana)

HH ( % )

HL ( % )

LL ( % )

LH ( % )

Num Jobs

Min Deg

Med Deg

Max Deg

Min Time (seg)

Med Time (seg)

Max Time (seg)

HPC2N 8,75 9,22 43,03 39,00 71 1 5 66 1 1.758 3.600 LANLCM5 11,76 13,59 47,61 27,04 13 32 156 512 2 1.250 3.600 SDSC 11,60 12,60 29,95 45,85 43 8 41 512 2 2.305 3.600

* Legenda: HH - alto nível de paralelismo - alto tempo de execução; HL - alto nível de paralelismo - baixo tempo de execução; LL - baixo nível de paralelismo - baixo tempo de execução; LH - baixo nível de paralelismo - alto tempo de execução; Num Jobs (Number of Jobs) - Número de tarefas submetidas; Min Deg (Minimum Degree) - Número mínimo de processos; Med Deg (Medium Degree) - Número médio de processos; Max Deg (Maximum Degree) - Número máximo de processos; Min Time (Minimum Time) - Tempo de execução mínimo; Med Time (Medium Time) - Tempo de execução médio; Max Time (Maximum Time) - Tempo de execução máximo. Fonte: Dados da pesquisa

A Tabela 8 acima mostra os dados comparativos entre as cargas utilizadas para a Fase

de Predição e para a Fase de Execução (ou Fase de Operação). Os dados são referentes às

médias de uma hora típica da semana calculada a partir da média da amostra utilizada. O

primeiro item a se analisar é sobre os tamanhos das amostras utilizadas. Para a Fase de

Predição (1ª parte da Tabela 8), utilizamos 1 mês de carga (ou N períodos de uma semana). Já

para a Fase de Execução da carga (2ª parte da Tabela 8), utilizamos 1 período, que é uma

semana. Os dados mostrados para as cargas utilizadas na Fase de Predição foram obtidos à

partir de agrupamento e modelagem estatística e calculados utilizando dados de um mês

inteiro como amostra. Para as cargas utilizadas na Fase de Execução (2ª parte da Tabela 8), os

dados foram gerados utilizando a primeira semana do mês subseqüente à carga utilizada para

a Fase de Predição como amostra. E é nesta Fase de Execução que testamos e verificamos o

RGSA com a CCC Proposta nesta pesquisa.

73

Analisando os dados da Tabela 8, podemos verificar que a carga SDSC possui as

características mais similares, considerando-se todas as colunas, e com menor variação entre a

utilizada para a Fase de Predição e a utilizada para a Fase de Execução.

Na Tabela 9 mostramos a comparação do RGSA com a CCC Proposta com relação às

12 configurações fixas para as cargas de trabalho utilizadas nesta pesquisa. Na coluna “RGSA

Melhor” é mostrado a quantidade de vezes que o RGSA com a CCC Proposta foi melhor

comparando com as 12 configurações fixas. A coluna “RGSA Igual”, por sua vez, mostra a

quantidade de vezes que o RGSA com a CCC Proposta foi igual à alguma das 12

configurações fixas. E a coluna “RGSA Pior”, a quantidade de vezes que o RGSA com a CCC

Proposta foi pior. Por fim, as duas últimas colunas, “Melhor Caso” e “Pior Caso”, mostram o

percentual de desempenho que o RGSA com a CCC Proposta obteve em relação à melhor e à

pior configuração fixa, respectivamente.

Tabela 9 - Comparação entre as configurações fixas e o RGSA com a CCC Proposta

para as cargas

Carga de Trabalho

RGSA com a CCC Proposta x Configurações Fixas Desempenho RGSA

RGSA Melhor RGSA Igual RGSA Pior Melhor Caso Pior Caso

HPC2N 8 3 1 24,51% -0,19%

LANLCM5 8 0 4 16,11% -4,04%

SDSC 6 0 6 96,74% -5,78% Fonte: Dados da pesquisa

Conforme mostrado na Tabela 8, a carga HPC2N utilizada na Fase de Predição possui

20,19% de tarefas com alto nível de paralelismo (HH + HL) e 79,81% com baixo nível de

paralelismo (LL + LH). Já a carga HPC2N utilizada na Fase de Execução possui 17,97% de

tarefas com alto nível de paralelismo (HH + HL) e 82,03% com baixo nível de paralelismo

(LL + LH). Porém, a diferença maior se dá no tempo médio de execução dos processos. Na

carga utilizada na Fase de Predição, esse tempo é de 2.688 segundos e na carga utilizada na

Fase de Execução, 1.758 segundos. Contudo, a carga HPC2N não sofreu muito impacto com

as alterações das configurações. Isso, porque a quantidade máxima de processos por tarefa

disparada foi de 64 para a carga utilizada na Fase de Predição e 66 para a utilizada na Fase de

Execução. E a quantidade de elementos de processamento (EP) no cluster simulado foi de

512. Como mostrado na Tabela 9, a variação de ganho do RGSA com a CCC Proposta foi de -

0,19% no pior caso e de 24,51% no melhor caso em relação ao desempenho. E em apenas

74

uma opção de configuração o RGSA com a CCC Proposta foi pior (8,33% das vezes) e nas

demais (91,67%), seu desempenho foi igual ou melhor que o das configurações fixas.

Para LANLCM5, a Tabela 8 mostra que a carga utilizada na Fase de Predição possui

39,65% das tarefas com alto nível de paralelismo (HH + HL) e 60,35% com baixo nível de

paralelismo (LL + LH). Já para a carga utilizada na Fase de Execução, 25,35% das tarefas

possuem alto nível de paralelismo (HH + HL) e 74,65% baixo nível de paralelismo (LL +

LH), o que mostra uma diferença considerável. Realizamos a Fase de Predição com

configurações propícias para uma carga com aproximadamente 40% de tarefas com alto nível

de paralelismo e 60% com baixo nível de paralelismo e após a predição das configurações, a

Fase de Execução foi executada com uma carga com 25% e 75%, respectivamente. Existem

também, diferenças consideráveis entre as cargas utilizadas na predição das configurações e

na Fase de Execução com relação à quantidade média de processos por tarefas disparadas e no

tempo médio de execução dos processos. Na carga utilizada na Fase de Predição, a quantidade

média de processos por tarefa foi de 124 e o tempo médio de execução dos mesmos foi de

1.659 segundos. E na carga utilizada na Fase de Execução a quantidade média foi de 156 e o

tempo médio 1.250 segundos. Apesar de o tempo médio ter diminuído na Fase de Execução, a

quantidade média de processos aumentou. E essas variações aconteceram em proporções

iguais, aumentando em 25,81% para a quantidade média de processos e diminuindo em

24,65% para o tempo médio de execução da carga utilizada na Fase de Predição com relação à

carga utilizada na Fase de Execução. Como mostrado na Tabela 9, a variação de ganho de

desempenho do RGSA com a CCC Proposta foi de -4,04% no pior caso e de 16,11% no

melhor caso. E em 2/3 das vezes (66,67%) o RGSA com a CCC Proposto foi melhor que as

configurações fixas.

Na carga SDSC, de acordo com a Tabela 8, a carga utilizada na Fase de Predição

possui 31,16% de tarefas com alto nível de paralelismo (HH + HL) e 68,84% de tarefas com

baixo nível de paralelismo (LL + LH). Já para a carga utilizada na Fase de Execução, 24,20%

das tarefas possuem alto nível de paralelismo (HH + HL) e 75,80% possuem baixo nível de

paralelismo (LL + LH). Isso mostra uma diferença considerável na divisão da carga utilizada

para Fase de Predição das configurações (1/3 com alto nível de paralelismo e 2/3 com baixo

nível de paralelismo) e na Fase de Execução (1/4 com alto nível de paralelismo e 3/4 com

baixo nível de paralelismo). Contudo, a diferença mais considerável se deu na coluna HH e

foi 38,23% menor da carga utilizada para predição das configurações com relação à carga

utilizada na Fase de Execução. Outras diferenças entre as cargas utilizadas nas Fases de

Predição e Execução foram na quantidade média de tarefas por hora (33 na de Predição e 43

75

na de Execução) e quantidade média de processos por tarefas disparadas (52 na de Predição e

41 na de Execução). Essa variação foi 30,30% maior na quantidade média de tarefas,

enquanto a quantidade média de processos por tarefa disparada foi de 21,15% menor, se

comparados a Fase de Predição em relação à Fase de Execução. Os ganhos para essa carga

foram consideráveis e os dados da Tabela 9 mostram a variação do RGSA com a CCC

Proposta de -5,78% no pior caso e de 96,74% no melhor caso. O RGSA com a CCC Proposta

foi melhor em 50% das vezes e nas outras 50% das vezes em que foi pior, o RGSA com a

CCC Proposta teve uma perda máxima de 5,78% no desempenho.

Tabela 10 - Tempo médio de execução das cargas de trabalho com as 12 configurações

fixas comparados ao RGSA com a CCC Proposta utilizadas na execução

Carga Tempo médio execução das

12 configurações fixas

Tempo RGSA com a CCC

Proposta

Desempenho RGSA com a CCC Proposta

HPC2N 867.993 804.200 7,93%

LANLCM5 987.373 943.700 4,63%

SDSC 1.730.972 1.489.420 16,22% Fonte: Dados da pesquisa

Outra comparação a se fazer é a do RGSA com a CCC Proposta com o tempo médio

de execução das 12 configurações fixas. Se considerarmos os tempos médios das 12

configurações fixas utilizadas na Fase de Execução e compararmos com os tempos do RGSA

com a CCC Proposta para as 3 cargas de trabalho utilizadas, percebemos que o RGSA com a

CCC Proposta foi melhor. Conforme mostrado na Tabela 10, a eficiência média do RGSA

com a CCC Proposta foi considerável e mostra que essa técnica é uma boa escolha como

controle de escalonamento reconfigurável de tarefas paralelas e que merece um estudo maior

em outras pesquisas.

4.5 Considerações Finais

Os resultados de verificação do RGSA utilizando a CCC Proposta foram realizados

somente com uma combinação de parâmetros de regularidade temporal. Os parâmetros desta

pesquisa são: (i) período; (ii) intervalo do período; e (iii) quantidade de períodos para

agrupamento e modelagem estatística da carga de trabalho e para a predição de configuração.

Esta combinação utilizou um período semanal, subdividido em intervalos de horas e

fundamentada na média das semanas do mês anterior (N períodos) à carga executada. O que

76

devemos deixar claro é que essa nossa hipótese de solução permite que utilizemos várias

outras combinações de parâmetros diferentes da utilizada neste trabalho.

Outro fator relevante que podemos ressaltar é que obtivemos resultados diferentes para

as cargas de trabalho utilizadas. O que podemos salientar é que a heterogeneidade ou a

homogeneidade do comportamento temporal das cargas em alguns momentos utilizados na

Fase de Predição das configurações utilizando agrupamento e modelagem estatística das

cargas de trabalho e fundamentada nas execuções destas cargas no passado pode ter

impactado diretamente em alguns resultados obtidos. E que provavelmente com outras

combinações de parâmetros podemos obter melhores resultados. E isso deve ser analisado

melhor futuramente em outros trabalhos.

77

5 CONCLUSÃO

Neste capítulo apresenta-se a conclusão da pesquisa onde são discutidos os resultados

da pesquisa, apresentadas as principais contribuições e indicados alguns dos possíveis

trabalhos futuros.

5.1 Discussão dos Resultados

Com relação aos testes, resultados e parâmetros de temporalidade utilizados nesta

pesquisa os nossos objetivos foram alcançados. Nos testes obtivemos resultados diferentes

para as cargas de trabalho devido à heterogeneidade das mesmas. Contudo, um estudo melhor

será realizado em trabalhos futuros para que os impactos dos diferentes parâmetros de

temporalidade possam ser analisados com mais detalhes. Entre os parâmetros estão o período,

os intervalos do período e a quantidade de períodos utilizados para a realização do

agrupamento e a modelagem estatística das cargas de trabalho. Isso porque para algumas

cargas foram observados ganhos maiores e para outras cargas, ganhos menores com relação

aos tempos de execução durante a Fase de Execução das cargas.

Porém, vale ressaltar o fato da nossa solução ter se mostrado sempre próxima das

melhores configurações fixas disponíveis no RGSA com pequenas perdas em relação aos

tempos de execução. Isso não tira o mérito do trabalho e mostra que a solução, além de

promissora, é viável e merece ser estudada com maior profundidade em trabalhos futuros.

É importante mostrar que esse novo controle de configuração que utiliza predição das

configurações fundamentada no agrupamento e na modelagem estatística das cargas de

trabalho executadas no passado trouxe ganhos médios em todas as comparações com as

configurações fixas, disponíveis no RGSA. Também, nos casos em que uma escolha aleatória

e sem critério de configuração acontecer, isso pode gerar uma perda de desempenho grande se

comparada com as demais configurações fixas disponíveis no RGSA. Assim, o RGSA

utilizando o novo controle de configuração incorporado na CCC obteve ganhos tanto em

comparação à média das 12 configurações fixas disponíveis no RGSA quanto a algumas das

configurações fixas comparadas isoladamente. E comparando o RGSA com a CCC Proposta e

as configurações fixas que se mostraram melhores que o mesmo, o desempenho foi, no pior

dos casos, 5,78% pior.

78

Assim, com relação à nossa proposta de CCC, os nossos objetivos foram alcançados

completamente. A CCC Proposta mostrou-se viável em relação à implementação e utilização

em sistemas de computação paralelos reais.

Os resultados alcançados nesta pesquisa se mostraram de acordo com os esperados em

nossos objetivos. O novo controle de configuração para escalonadores reconfiguráveis de

tarefas paralelas utilizando predição das configurações baseada na temporalidade das cargas

de trabalho executadas no passado foi implementado na CCC Proposta do RGSA. Este novo

controle se mostrou um meio interessante e promissor, além de produzir bons resultados. Os

mesmos foram satisfatórios e sempre próximos do melhor resultado para todas as cargas de

trabalho utilizadas nesta pesquisa.

A comparação do RGSA com a CCC Proposta com o RGSA com a CCC Proposta

utilizando as configurações ideais ou ótimas foi realizada utilizando a heurística de

aproximação que descrevemos nesta pesquisa para o RGSA Aproximado. O RGSA

Aproximado foi melhor que o RGSA com a CCC Proposta para 1 das cargas de trabalho.

Assim, essa heurística deve ser melhorada com o estudo de uma forma melhor de

aproximação do RGSA com a CCC Proposta contendo as configurações ótimas.

5.2 Principais Contribuições

A principal contribuição deste trabalho é a apresentação de um novo controle de

configuração para escalonadores reconfiguráveis de tarefas paralelas que utiliza a predição

das configurações baseada na regularidade temporal das cargas de trabalho executadas no

passado. Este controle foi implementado na Camada de Controle de Configuração (CCC) do

RGSA, que chamamos de CCC Proposta. Este novo controle é uma evolução da CCC do

RGSA Original, a qual realiza a reconfiguração do escalonador baseado na anotação das

cargas que são enviadas juntamente com a própria carga no momento de submissão. O RGSA

com a CCC Proposta está mais próximo da realidade com a inclusão do novo controle de

configuração proposto nesta pesquisa. O RGSA com a CCC Proposta não necessita da

anotação das cargas de trabalho para escolher a configuração que o escalonador irá utilizar.

Ele, utilizando este novo controle de configuração, usa a predição fundamentada em

agrupamento e modelagem estatística da carga de trabalho para predizer as configurações

baseando-se nas execuções de cargas passadas para as tomadas de decisão.

79

5.3 Trabalhos Futuros

Entre os possíveis trabalhos futuros, podemos citar a investigação de outros conjuntos

de parâmetros de temporalidade na proposta do controle de configuração que foi utilizada na

CCC Proposta. Entre estes conjuntos de parâmetros, destacamos a variação dos intervalos de

período utilizados nesta pesquisa. Podemos, ao invés de utilizar as horas de uma semana,

utilizar intervalos menores como minutos, ou maiores como turnos (manhã, tarde, noite).

Como outro trabalho futuro, podemos utilizar outras técnicas de caracterização de

cargas de trabalho e compará-las com a técnica utilizada nesta pesquisa.

Outro trabalho futuro está no teste e verificação da predição das configurações ao

longo de vários períodos seguidos. Ou seja, a Fase de Predição de períodos adjacentes futuros

utilizando N períodos anteriores funcionando como uma janela deslizante, se deslocando à

medida que os períodos forem chegando. Com isso, teremos que automatizar a realização da

Fase de Predição das configurações para as cargas de trabalho futuras, para que seja realizada

durante a Fase de Execução de cargas atuais. Assim, a CCC Proposta utilizará as

configurações preditas com cargas de trabalho mais recentes possíveis.

Pretendemos investigar a heurística de aproximação que utilizamos para extrair os

resultados do RGSA Aproximado, pois precisa ser melhorada. E, também, analisar as razões

da Configuração 07 ter sido a pior configuração para todas as cargas de trabalho utilizadas

nesta pesquisa.

A utilização e experimentação da CCC Proposta do RGSA em um ambiente real não

simulado é um outro trabalho futuro para mostrar que este novo controle de configuração

pode ser interessante e mostrar bons resultados na prática.

Uma análise da utilização e ocupação do computador paralelo por intervalo de tempo

precisa ser realizada para sabermos o impacto da quantidade de EPs utilizados e não

utilizados nestes tempos.

Precisamos também, melhorar e automatizar algumas funcionalidades no simulador

ClusterSim para agilizar a análise das cargas de trabalho executadas de acordo com as

configurações utilizadas no computador paralelo configurado no simulador. Também é

interessante reduzirmos os tempos com simulação para que possam ser realizadas mais

operações no mesmo espaço de tempo, com o intuito de melhorar as análises nos estudos.

O uso do RGSA em outras plataformas de computação paralela como, por exemplo,

no contexto de Cloud Computing, é um outro trabalho futuro.

80

Por fim, citamos o estudo para que seja utilizado este novo controle de configuração

fundamentado na predição das configurações baseada na regularidade temporal das cargas de

trabalho executadas no passado em outros escalonadores configuráveis ou reconfiguráveis de

tarefas paralelas diferentes do RGSA Original (GÓES; MARTINS, 2004a).

81

REFERÊNCIAS

ALMASI, George S.; GOTTLIEB, Allan. Highly parallel computing, 2nd ed. Redwood City: Benjamin-Cummings Publishing Company, 1994. BATAT, Anat; FEITELSON, Dror G. Gang scheduling with memory considerations. In IEEE INTERNATIONAL PARALLEL AND DISTRIBUTED PROCESSING SYMPOSIUM, 14, 2000, Cancun. Proceedings. p. 109-114. BUYYA, Rajkumar. High performance cluster computing: architectures and systems, 1st ed. New Jersey: Prentice Hall, 1999, v. 1. CAMPOS, Luis M., Resource management techniques for multiprogrammed distributed systems. 1999. 131f. Tese (Doutorado) - University of California, Irvine. CLEMENTE, Juan A. et al. A hardware task-graph scheduler for reconfigurable multi-tasking systems. In RECONFIG - INTERNATIONAL CONFERENCE ON RECONFIGURABLE COMPUTING AND FPGAS, 08, 2008, Cancun. Paper, p. 79-84. EL-REWINI, Hesham; ALI, Hesham H.; LEWIS, Ted. Task scheduling in multiprocessing systems. IEEE COMPUTER , v. 28, n. 12, p. 27-37, Dec. 1995. EXPERIMENTAL SYSTEMS LAB. The Hebrew University – Experimental Systems Lab. Laboratório da universidade Hebrew University of Jerusalem, Israel. Disponível em <http://www.cs.huji.ac.il/labs/parallel/> Acesso em: 19 dez. 2008.

FEITELSON, Dror G. A survey of scheduling in multiprogrammed parallel systems. Yorktown Heights: IBM T. J. WATSON RESEARCH CENTER, 1997. Research Report RC 19790 (87657). FLYNN, Michael J. Very high-speed computing systems. Proceedings of the IEEE, v. 54, n. 12, p. 1901-1909, Dec. 1966. FLYNN, Michael J. Some computer organizations and their effectiveness. IEEE Transactions on Computers, v. c-21, n. 9, p. 948-960, Sep. 1972. FRACHTENBERG, Eitan; SCHWIEGELSHOHN, Uwe. New challenges of parallel job scheduling. In: INTERNATIONAL CONFERENCE ON JOB SCHEDULING STRATEGIES FOR PARALLEL PROCESSING, 13, 2007, Seattle. Proceedings, p. 1-23. FRANKE, Hubertus et al. An evaluation of parallel job scheduling for ASCI Blue-Pacific. In: ACM/IEEE CONFERENCE ON SUPERCOMPUTING, 99, 1999, Portland. Proceedings, artigo n. 45. FREITAS, Edison P. et al. Dynamic reconfigurable task schedule support towards a reflective middleware for sensor network. In: INTERNATIONAL SYMPOSIUM ON PARALLEL AND DISTRIBUTED PROCESSING WITH APPLICATIONS, 08, 2008, Sydney. Proceedings, p. 886-891.

82

GÓES, Luis F. W.; MARTINS, Carlos A. P. S. RJSSim: a reconfigurable job scheduling simulator for parallel processing learning, ASEE/IEEE FRONTIERS IN EDUCATION CONFERENCE, 33, 2003, Colorado. Paper, p. F3C3-F3C8. GÓES, Luis F. W.; MARTINS, Carlos A. P. S. Reconfigurable gang scheduling algorithm. In: WORKSHOP ON JOB SCHEDULING STRATEGIES FOR PARALLEL PROCESSING, 10, 2004a, New York. Paper, p.81-101. GÓES, Luis F. W.; MARTINS, Carlos A. P. S. Proposta e desenvolvimento de um algoritmo reconfigurável de escalonamento paralelo de tarefas. 2004b. 141f. Dissertação (Mestrado), Pontifícia Universidade Católica de Minas Gerais, Programa de Pós-Graduação em Engenharia Elétrica, Belo Horizonte. GÓES, Luis F. W.; RAMOS, Luiz E. S.; MARTINS, Carlos A. P. S. ClusterSim: a java-based parallel discrete-event simulation tool for cluster computing, IEEE INTERNATIONAL CONFERENCE ON CLUSTER COMPUTING, 2004, 2004, San Diego. Proceedings, p. 401-410. HWANG, Kai; XU, Zhiwei. Scalable parallel computing: technology, architecture, programming, 1st ed. San Francisco: McGraw-Hill Book Company, 1998. JETTE, Morris A. Performance characteristics of gang scheduling in multiprogrammed environments. In: ACM/IEEE CONFERENCE ON SUPERCOMPUTING, 97, 1997, San Jose. Technical Paper, artigo n. 54. KWOK, Yu K.; AHMAD, Ishfaq. Static scheduling algorithms for allocating directed task graphs to multiprocessors, ACM Computing Surveys, v. 31, n. 4, p. 406-471, Dec. 1999. LOS ALAMOS NATIONAL LAB. Laboratório Los Alamos national lab nos EUA. Disponível em <http://www.lanl.gov/> Acesso em: 1 mar. 2011 MARTINS, Carlos A. P. S. et al, Computação reconfigurável: conceitos, tendências e aplicações. In: CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 23. JORNADA DE ATUALIZAÇÃO EM INFORMÁTICA, 22, 2003, Campinas. Anais... Cap. 8, p. 339-388. MAUI CLUSTER SCHEDULER. Link do Projeto Open Source do Escalonador de tarefas Maui cluster scheduler. Disponível em <http://www.clusterresources.com/products/maui/> Acesso em: 1 mar. 2011

MONTANA, David; HUSSAIN, Talib; VIDAVER, Gordon. A genetic-algorithm-based reconfigurable scheduler. In: DAHAL, Keshav P.; TAN, Kay C.; COWLING, Peter I. (Org.). Studies in computacional intelligence: evolutionary scheduling, Warsaw: Springer, 2007. v. 49, cap. 21, p. 577-611.

OUSTERHOUT, John K. Scheduling techniques for concurrent systems. In: INTERNATIONAL CONFERENCE ON DISTRIBUTED SYSTEMS, 3, 1982, Miami. Proceedings, p. 22-30.

83

PAN, Zexin; WELLS, Buren E. Hardware supported task scheduling on dynamically reconfigurable SoC architectures. IEEE Transactions on Very Large Scale Integration Systems, v. 16, n. 11, p. 1465-1474, Nov. 2008. SANTOS, Lesandro P.; SILVA, João P. D.; GÓES, Luis F. W. Técnica de caracterização de cargas de trabalho de supercomputadores para predição do comportamento de tarefas paralelas. REIC - Revista Eletrônica de Iniciação Científica, Brasil, ano 9, n. 1, março, 2009. Disponível em: <http://portal.sbc.org.br/index.php?language=1&subject=101&content= article&option=pdf&aid=632 >. Acesso em: 24 nov. 2009. STERLING, Thomas; STARK, Dylan. A high-performance computing forecast: partly cloudy. Computing in Science & Engineering, v. 11, n. 4, p. 42-49, Jul. 2009. THE STANDARD WORKLOAD FORMAT. Link do laboratório experimental systems lab da universidade The Hebrew University que detalha o formato padrão de carga de trabalho SWF (Standard Workload Format). Disponível em <http://www.cs.huji.ac.il/labs/parallel/workload/swf.html/> Acesso em: 1 mar. 2011 YAMIN, Adenauer C. Escalonamento em sistemas paralelos e distribuídos. In: ESCOLA REGIONAL DE ALTO DESEMPENHO, 1, 2001, Gramado. Anais… p.75-126. WISEMAN, Yair; FEITELSON, Dror G. Paired gang scheduling. IEEE Transactions Parallel & Distributed Systems, v. 14, n. 6, pp. 581-592, Jun. 2003. ZHANG, Yanyong et al. Improving parallel job scheduling by combining gang scheduling and backfilling techniques. In: IEEE INTERNATIONAL PARALLEL AND DISTRIBUTED PROCESSING SYMPOSIUM, 14, 2000, Cancun. Paper, p.133-142. ZHOU, Bing B. et al. An efficient resource allocation scheme for gang scheduling. In: IEEE COMPUTER SOCIETY INTERNATIONAL WORKSHOP ON CLUSTER COMPUTING, 1, 1999, Melbourne. Proceedings, p. 187-194.

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS … · Para isso, utilizamos o algoritmo Reconfigurable...

Documents

Transcript of PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS … · Para isso, utilizamos o algoritmo Reconfigurable...