Arquitetura em Hardware para Co-processamento de Tarefas em Sistema Operacional Tempo Real

Transcrição

1 Arquitetura em Hardware para Co-processamento de Tarefas em Sistema Operacional Tempo Real Gonçalves Júnior H. J. *, Hüsemann R. *, Becker L. B. #, Pereira C. E. * * Departamento de Engenharia Elétrica, UFRGS Osvaldo Aranha 103, Porto Alegre RS, BRASIL {hermes, husemann, cpereira}@eletro.ufrgs.br # Instituto de Informática, UFRGS e Faculdade de Informática, PUCRS lbecker@inf.ufrgs.br Resumo O emprego de sistemas operacionais tempo real em sistemas computacionais ou aplicações embarcadas tem como principal vantagem oferecer a flexibilidade de um sistema multitarefa sem perder o determinismo temporal. O principal fator de determinismo temporal em um sistema operacional tempo real é o escalonador de tarefas. Sabe-se que o emprego de algoritmos de escalonamento mais sofisticados tende a tornar sistema mais flexível. Entretanto, estes algoritmos mais complexos tendem a aumentar a sobrecarga computacional no sistema, o que acaba limitando o seu emprego em algumas aplicações. Para minimizar este problema, o presente trabalho apresenta uma arquitetura de co-processamento de tarefas em hardware que objetiva reduzir a sobrecarga introduzida pelo algoritmo de escalonamento. Esta arquitetura é composta por um computador IBM-PC compatível equipado com um hardware adicional de co-processamento, o qual é interligado ao PC através de uma interface PCI. O computador executa o sistema operacional tempo real RTlinux-3.0, o qual fora adaptado para permitir que o escalonador execute no hardware adicional. Para validar a arquitetura proposta, implementou-se o escalonador TAFT (Time-Aware Fault-Tolerant) no co-processador. O presente artigo contém ainda uma análise do ganho de desempenho obtido com a implementação da arquitetura proposta. Palavras-chaves: Escalonamento de tarefas, sistema operacional tempo real, arquitetura de co-processamento, sistemas embarcados. Abstract Real-time operating systems are a key component in several computer-based and embedded applications, allowing the development of multi-task concurrent applications with deterministic temporal behavior. The scheduler is the main part of any real-time operating system. Advanced scheduling algorithms should allow the development of flexible real-time systems, which may adapt to different workloads while still meeting the deadlines. However, these algorithms increase the computational overload, since they usually compete with concurrent tasks for the processor and this can restrict their use in some applications. This paper presents a hardware-supported co-processing architecture, which aims to reduce the computational overload caused by the scheduler. The proposed architecture is based on standard IBM-PC compatible computer running the Rtlinux-3.o real-time operating system and interconnected with an external co-processing board through the PCI interface. The realtime kernel is modified to support the execution of scheduling algorithms and other operating system functionalities in the additional hardware. The system has been validated with the implementation of a TAFT (Time-Aware Fault-Tolerant) scheduling algorithm. The paper also includes a performance analysis of the proposed architecture.

2 Keywords: Real-time schedulers, real-time operational systems, co-processing architecture, embedded systems. 1 Introdução Em sistemas tempo real o não cumprimento de requisitos temporais, como um deadline, pode levar a instabilidade do sistema ou até mesmo causar graves danos. Daí a necessidade em se utilizar sistemas computacionais que possuam comportamento temporal determinístico. Tradicionalmente, a adoção de sistemas operacionais tempo real (SOTR) vem sendo utilizada como uma solução bastante viável neste sentido. Os SOTR permitem o desenvolvimento de aplicações multitarefas, sendo responsabilidade do escalonador o gerenciamento das mesmas de modo a respeitar os seus tempos de ativação e deadlines. A escolha entre o melhor algoritmo de escalonamento depende do tipo de aplicação a ser desenvolvida. Escalonadores estáticos, como o Rate Monotonic [1], são geralmente mais eficientes uma vez que utilizam prioridades fixas. Entretanto, a utilização dos mesmos se caracteriza por ser pouco flexível e também por limitar o fator de utilização do processador. Já os escalonadores dinâmicos, como o Earliest Deadline First, são mais flexíveis, porém normalmente mais lentos por precisarem estar continuamente recalculando a ordenação das tarefas. Quanto mais sofisticado for o algoritmo de escalonamento, maior a sobrecarga introduzida ao sistema, deixando assim menos tempo de CPU disponível para as tarefas da aplicação. Visando reduzir a sobrecarga computacional introduzida pelo algoritmo de escalonamento no processador principal, propõe-se neste trabalho uma arquitetura capaz de executar o algoritmo de escalonamento em uma unidade computacional dedicada [6]. Assim, por mais complexo que seja, o algoritmo de escalonamento não irá consumir recursos do processador em excesso, deixando-os disponíveis para as tarefas da aplicação. Esta arquitetura é composta por um computador IBM-PC compatível equipado com um hardware adicional de co-processamento, o qual é interligado ao PC através de uma interface PCI. No computador executa-se o sistema operacional tempo real RTlinux-3.0, o qual fora adaptado para permitir que o escalonador seja executado no hardware adicional. Para validar a arquitetura proposta, implementou-se o escalonador TAFT(Time-Aware Fault-Tolerant) [2; 3] no co-processador de escalonamento. Além disso foram realizados experimentos práticos, os quais comprovam as vantagens da abordagem proposta. O restante do artigo está dividido da seguinte forma: a seção 2 apresenta uma descrição da arquitetura proposta, definindo-se a plataforma em hardware utilizada e os módulos de software desenvolvidos; a seção 3 descreve a validação do sistema juntamente com a análise dos resultados; a seção 4 apresenta as conclusões observadas e os trabalhos futuros. 2 Arquitetura Proposta Na arquitetura proposta, o algoritmo de escalonamento do SOTR é executado no hardware de co-processamento. Desta forma, o processador principal se responsabiliza apenas pelo despacho das tarefas (ao invés de ter que escaloná-las). Isto significa que o mesmo tem por função executar o chaveamento de contexto entre as tarefas, conforme definido pelo escalonador. A figura 1 ilustra a configuração da arquitetura proposta em comparação com uma arquitetura tradicional.

3 A seguir são descritas em maiores detalhes as duas partes principais da arquitetura desenvolvida: hardware da placa de co-processamento e estrutura do software de gerenciamento (SOTR modificado). Figura 1: Comparação entre arquitetura tradicional e a arquitetura proposta 2.1 Placa do Co-processador Para desenvolvimento do co-processador de escalonamento foi utilizado como base uma placa microprocessada, a qual havia sido desenvolvida originalmente para executar a monitoração e a captura de eventos em uma rede de barramentos industriais. Esta reutilização só foi possível graças a sua arquitetura genérica. Uma representação da arquitetura de hardware utilizada encontra-se na figura 2, onde se pode observar suas três partes funcionais: interface PCI, memória compartilhada e a unidade de processamento. Figura 2: Representação da placa do co-processador A placa utiliza um microprocessador de 32 bits da família Coldfire da Motorola como unidade de processamento. A freqüência de operação do microprocessador é de 40MHz, como performance de até 33MIPS, o que é suficiente para atender requisitos temporais na faixa de 50 microssegundos segundo testes realizados. Esta é uma resolução considerada satisfatória, principalmente se comparada aos sistemas operacionais tradicionais que garantem resolução temporal de algumas unidades de milissegundos. Para os testes de validação da arquitetura proposta foi implementado no co-processador o mecanismo de escalonamento TAFT. Este microprocessador é o principal elemento da placa de coprocessamento, pois nele são executados os algoritmos de escalonamento que interagem com o SOTR. A escolha do barramento de comunicação PCI para interface entre a processador do PC e a placa se deve à necessidade de altas velocidades nas trocas de dados. Na placa de coprocessamento, a implementação da interface PCI da placa foi feita utilizando-se um chipset comercial PLX Este componente possibilita leituras e escritas em rajada, a uma taxa de comunicação próxima a 132 MB/s (33MHz e 32 bits) e prevê detecção de erros de paridade em dados ou endereços durante as transações.

4 Para a comunicação entre os dispositivos, o chipset PLX e o microprocessador Coldfire foi montado um banco de memórias dupla porta, que possibilita acessos simultâneos por ambos os componentes. O banco de memória de tamanho máximo de 16Kbytes foi organizado como duas FIFOs circulares, uma para escrita de dados a partir do microprocessador e outra para escritas a partir do chipset PCI. Entre os dados trocados entre o PC e a placa do co-processador através do barramento PCI se destacam os atributos das tarefas e também algumas informações operacionais para o acompanhamento das aplicações. 2.2 Estrutura do Software de Gerenciamento Elementos de Software no PC A arquitetura de software desenvolvida consiste de um novo módulo de escalonamento para o RT-Linux (agora chamado dispatcher), o qual opera em conjunto com diversos módulos adicionais. A figura 3 apresenta uma visão geral da configuração destes módulos. Figura 3: Arquitetura de software desenvolvida O módulo Driver PCI é responsável por garantir a comunicação entre o PC e o hardware de co-processamento. O mesmo foi desenvolvido com base em um pacote de desenvolvimento adquirido da empresa fabricante do chipset PLX utilizado no projeto. Este pacote foi adaptado para a arquitetura proposta, permitindo acesso de leitura e escrita no banco de memórias da placa. Isto é feito através de um aplicativo próprio desenvolvido para servir de interface entre o escalonador, que roda na placa externa, e o programa residente no PC. Devido ao fato deste pacote ter sido inicialmente projetado para trabalhar em plataformas não tempo real, este módulo segue a mesma restrição. Já o módulo Dispatcher atende às solicitações do escalonador (que executa no coprocessador externo). As funções deste módulo são de receber dados gerados pelo escalonador quando da necessidade de ativar ou desativar alguma dada tarefa e garantir sua execução no processador principal. Em resumo, sua função é a de despachar os comandos gerados pelo escalonador e por isso foi chamado de dispatcher. Este módulo pode também enviar informações para o escalonador, como por exemplo, a indicação da finalização de uma tarefa. Como o aplicativo de leitura do driver PCI é uma tarefa não tempo real e o dispatcher é uma aplicação tempo real, a comunicação entre ambos ocorre através de uma RT-FIFO [4].

5 Além disso, utilizou-se a ferramenta de monitoração descrita em [2] para validar o sistema desenvolvido. Através dos dados obtidos com a monitoração foi possível validar o comportamento temporal da arquitetura desenvolvida Algoritmo de escalonamento do co-processador O mecanismo de escalonamento TAFT permite a execução de tarefas caracterizadas por um tempo de execução estimado. Este mecanismo é capaz de tratar situações de sobrecarga transiente, evitando a perda de deadlines. No TAFT, cada tarefa é designada como um par, denominado como TaskPair (TP), que tem um único deadline. Este par de tarefas tem definido uma parte principal, a MainPart (MP), e uma parte de exceção, a ExceptionPart (EP). É da seleção entre MP e EP que se resume o aspecto tolerante a falhas da política de escalonamento TAFT. Na MP encontram-se as funcionalidades das aplicações, enquanto que a EP somente é acionada se a sua MP correspondente não puder ser finalizada antes do seu respectivo deadline. Assim, o mecanismo de escalonamento ativa a EP de forma a garantir que pelo menos ela seja concluída antes do seu deadline. Ao contrário da MP, que possui o código da aplicação, na EP tem-se o mínimo de funcionalidade implementada, assegurandose apenas que a aplicação vá para um estado seguro. 3 Validação do Sistema 3.1 Apresentação do Estudo de Caso Para validar a arquitetura proposta, foram definidos alguns ensaios. Para a realização destes ensaios, acoplou-se a placa de co-processamento em um computador IBM-PC equipado com processador ATHLON com freqüência de 1096,136 MHz e 256 MB de memória RAM. Além disso, definiu-se um conjunto com dois pares de tarefas (TPs), as quais são caracterizados na tabela 1. Esta tabela contém informações sobre o período, o deadline, o tempo de execução esperado da MP e o tempo de execução de pior caso da EP. Tabela 1: Parâmetros dos TaskPairs utilizados nos ensaios TP Período Deadline Tp. MP Tp. EP 1 1 s 1 s 120 ms 16 ms 2 2 s 2 s 520 ms 4 ms Primeiramente, caracterizou-se o comportamento do algoritmo de escalonamento implementado no co-processador. Para tanto, procurou-se observar a existência de jitter na ativação das instâncias dos TPs a cada período. Em um segundo experimento, realizou-se um estudo com a finalidade de caracterizar os tempos de comunicação entre o escalonador (localizado na placa de co-processamento) e o mecanismo de despacho do SOTR. Mais precisamente, determinou-se o jitter entre o instante de tempo em que o co-processador de escalonamento determina o início de uma tarefa (MP ou EP neste caso) e o instante de tempo em que o dispatcher atende tal solicitação. No último experimento, comparou-se o desempenho do dispatcher em relação ao algoritmo de escalonamento. Neste ensaio, manteve-se o escalonador desenvolvido originalmente para o TAFT no ambiente RT-Linux (vide [2]). Além disso, testou-se também o uso de escalonadores mais simples, como o EDF.

6 3.2 Análise dos Resultados No primeiro ensaio foram analisadas estatisticamente as aquisições de pontos. A tabela 2 mostra a análise dos instantes de início das MPs no co-processador de escalonamento, determinando a média e o desvio padrão destes instantes, calculados através de um conjunto com 100 amostras. Analisando estes resultados, é possível concluir que o coprocessador trabalha com uma boa precisão, dado o pequeno jitter observado entre os instantes de ativação de cada MP. Tabela 2: Análise estatística do início de cada MP no co-processador de escalonamento TP Período Médio Desvio Padrão 1 1,005 s 577 µs 2 2,001 s 602 µs Analisando os resultados do segundo ensaio com o auxílio da ferramenta de análise BR-Tool, descrita em [5], torna-se possível quantificar os tempos de comunicação entre o driver PCI e o mecanismo de despacho. Através dos ensaios realizados, observou-se que os tempos de comunicação variam entre poucos microssegundos até 5 milisegundos. A figura 4 mostra a distribuição dos tempos medidos nesta faixa, tomando-se como base o envio do sinal que indica a ativação da MP do TP-1. A explicação para tal variação vem do fato que os eventos produzidos pelo co-processador são enviados para o processador principal e, neste último, bufferizados em uma RT-FIFO. Esta última só é lida a cada ativação do dispatcher, cujo tick está calibrado em 5 ms. Uma forma de otimizar este tempo é evitar a comunicação entre o driver PCI e o dispatcher através de RT-FIFO. Entretanto, isto só seria possível caso o driver fosse implementado também como um módulo tempo real, assim como o dispatcher. Figura 4: Atraso na marcação dos eventos entre dispatcher e aplicativo Realizou-se também uma análise estatística semelhante àquela realizada no primeiro ensaio, porém com o objetivo de determinar as diferenças entre os instantes em que os eventos são detectados pelo driver PCI no processador principal (PC) e os instantes em que são gerados pelo escalonador. As figuras 5 e 6 exibem a distribuição dos eventos no tempo em ambas localizações, ou seja, driver PCI (B) e dispatcher (A). Observa-se que no dispatcher os eventos são mais concentrados. Isto pode ser explicado pelo fato do dispatcher

7 executar periodicamente a cada 5 ms, sendo que os eventos são lidos e processados apenas nestes instantes. Já o driver PCI encontra-se em execução sempre que não houver outro aplicativo tempo real concorrendo pelo uso do sistema, o que ocorre com bastante freqüência neste experimento dado a baixa carga do sistema. 5A 5B Figura 5: Evento de início da MP do TP-1 no driver PCI e no dispatcher 6A 6B Figura 6: Evento de início da MP do TP-2 no driver PCI e no dispatcher Através das figuras, observa-se um jitter de até 50ms em torno dos instantes de ativação das tarefas. Uma análise mais apurada destes dados é apresentada na tabela 3. Interpretando tais resultados, nota-se que esta variação ocorre devido aos processos de comunicação e aquisição no processador principal (PC). Isto porque os dados apresentados na tabela 2 indicam que as tarefas são escalonadas com uma boa precisão na placa coprocessadora. Observando-se os eventos no driver PCI (parte A das figuras), verifica-se que os mesmos já são detectados com uma defasagem de até 50 ms. Portanto, o driver PCI é o causador principal da defasagem verificada. Isto se deve ao fato do driver PCI não ser um aplicativo tempo real, possuindo prioridade baixa em relação às demais tarefas do sistema. Para finalizar, ressalta-se que o maior jitter no dispatcher ocorre devido aos atrasos de comunicação do mesmo com o driver PCI, conforme exibido na figura 4. Tabela 3: Análise estatística dos eventos no processador principal (PC) TP-1 TP-2 Período Médio Desvio Padrão Período Médio Desvio Padrão Driver-PLX s ,26 ms s ,61 ms Dispatcher s ,39 ms s ,74 ms

8 No último ensaio realizado, comparou-se o desempenho temporal do dispatcher em relação ao algoritmo de escalonamento TAFT implementado no processador Coldfire. Neste teste, percebeu-se que o desvio padrão dos eventos no dispatcher é 11% maior do que no escalonador TAFT do co-processador, para a tarefa de maior período. Em uma primeira análise, este fator parece ser baixo. Entretanto, leva-se em consideração o fato de que neste ensaio executam apenas 2 tarefas. Assim, a sobrecarga introduzida por algoritmos de escalonamento mais complexos (como o TAFT) torna-se baixa devido ao pequeno número de tarefas no sistema. Acredita-se que esta diferença deva aumentar consideravelmente com o acréscimo no número de tarefas. 4 Conclusões e trabalhos futuros O presente artigo apresenta uma arquitetura para o co-processamento de tarefas, a qual pode ser facilmente adaptada em qualquer sistema operacional tempo real. A principal vantagem desta arquitetura encontra-se em permitir uma diminuição na sobrecarga causada pelo algoritmo de escalonamento, deixando assim mais tempo de CPU disponível para o processamento das tarefas do sistema. Os resultados preliminares discutidos neste trabalho são motivadores, uma vez que comprovam a diminuição de sobrecarga esperada. Além disso, acredita-se que o ganho percebido (de 11%) no desvio padrão para detecção de eventos venha a ter maiores proporções com o acréscimo no número de tarefas do sistema. Além disso, os resultados também demonstram que, na atual implementação, existe uma grande defasagem de tempo em relação ao processo de comunicação entre o escalonador localizado no co-processador e o processador principal (PC). Isto se deve principalmente ao fato do driver PCI não ser um aplicativo tempo real, possuindo prioridade baixa em relação às demais tarefas do sistema. Como trabalho futuro, destaca-se a migração do atual driver PCI para um módulo tempo real. Com isto, acredita-se obter uma melhora significativa com relação ao jitter observado na arquitetura. 5 Referências: [1] LIU C. L., LAYLAND J. W. Scheduling algorithms for multiprogramming in a hard real time environment, Journal of the Association for Computing Machinery, v.20, n.1, January 1973, pp [2] BECKER, L. Um Método para Abordar todo o Ciclo de Desenvolvimento de Aplicações Tempo Real, 2003, Tese de doutorado Programa de Pós-Graduação em Computação, Universidade Federal do Rio Grande do Sul, Porto Alegre. [3] BECKER, L., PEREIRA.C. E. Proposta de mecanismo para o escalonamento dinâmico de tarefas tempo real tolerante a falhas,. In: IV Workshop de Tempo Real, Búzios, RJ, 2002, pp [4] BARABANOV, M. A Linux-based Real-Time Operating System M.Sc. Thesis, New Mexico Institute of Technology. [5] HUSEMANN, R., PEREIRA, C. E. Avaliação Prática de Redes de Barramento de Campo Utilizando a Ferramenta BR-Tool, Anais do VI Simpósio Brasileiro de Automação Inteligente, Bauru, São Paulo, 2003, pp [6] ANDREWS, D., NIEHAUS, D., ASHENDEN, P. Programming Models for Hybrid CPU/FPGA Chips, IEEE Computer, Vol. 37, No. 1, Jan. 2004, pp