Notas da Aula 11 - Fundamentos de Sistemas Operacionais

Transcrição

1 Notas da Aula 11 - Fundamentos de Sistemas Operacionais 1. Escalonamento de Tempo Real Em sistemas de tempo real, o objetivo principal do escalonador é garantir que todos os processos sejam executados dentro dos prazos determinados pelos usuários. Outros objetivos, portanto, como reduzir o tempo de resposta ou aumentar a vazão do sistema, se tornam secundários. Para garantir que um conjunto de processos (também chamados de tarefas, neste tipo de sistema) tenha seus prazos sempre atendidos, o escalonador precisa verificar inicialmente se o hardware do sistema é capaz de executar as tarefas desejadas no tempo estabelecido. Para isso, é necessário conhecer os tempos de execução dos processos no hardware em questão. O problema de conhecer o tempo de execução de um processo previamente ocorre também no escalonador SJF. No SJF, este problema é resolvido em geral através do emprego de métodos de previsão. Os possíveis erros destes métodos, no entanto, são inaceitáveis nos sistemas de tempo real, fazendo com que a utilização dos mesmos não seja indicada. Além disso, sistemas de tempo real são geralmente muito bem planejados e controlados, fazendo com que seja possível medir previamente os tempos máximos de execução das tarefas do sistema. Logo, nos escalonadores de tempo real, supõe-se o conhecimento prévio deste valor. Além do tempo máximo de execução de cada tarefa, são parâmetros conhecidos pelo escalonador: período da tarefa: inverso da frequência de execução da tarefa; e prazo da tarefa: tempo máximo de execução da tarefa, uma vez que a mesma seja criada no sistema. Neste tipo de sistema, em geral, supõe-se que as tarefas sejam periódicas. Ou seja, de tempos em tempos há necessidade de execução. Desta forma, toda tarefa tem uma frequência de execução, ou seja, uma periodicidade com a qual a mesma é executada. O inverso desta frequência é o período da tarefa. Em outras palavras, o intervalo de tempo entre a criação de duas instâncias da tarefa. Geralmente, supõe-se que o período de uma tarefa seja igual ao seu prazo. Isso quer dizer que uma vez que uma tarefa é criada, ela pode ter sua execução completada em qualquer instante de tempo, desde que antes da criação da próxima instância desta mesma tarefa. Esta suposição, bem como a de que o sistema é composto apenas por tarefas periódicas, simplifica bastante a análise das políticas de escalonamento. O algoritmo de escalonamento mais simples para este tipo de sistema é o Taxa Monotônica. Neste algoritmo, cada tarefa recebe uma prioridade fixa, inversamente proporcional ao seu período. Ou seja, quanto maior for o período da tarefa, menor é a sua prioridade. Uma vez que as prioridades tenham sido atribuídas, este escalonador funciona de maneira idêntica a um

2 escalonador baseado em prioridades: toda vez que uma oportunidade de escalonamento se apresenta, o processo de mais alta prioridade é colocado no processador. Vale ressaltar que este escalonador é preemptivo. Ou seja, a chegada de um novo processo à lista de aptos faz com que o escalonador reavalie sua decisão. Em sistemas de tempo real, é comum existir a figura do escalonador de longo prazo. Este escalonador, como já estudado, tem o objetivo de controlar a entrada de novas tarefas no sistema, verificando se o sistema tem condições de atender a todas. No caso dos sistemas de tempo real, isso significa verificar se o escalonador é capaz de alocar o processador a todas as tarefas de modo a garantir os prazos. Isto é chamado de Teste de Escalonabilidade. Para o algoritmo de taxa monotônica, o teste de escalonabilidade pode ser realizado através da verificação da seguinte condição: onde U é a utilização do processador, é o tempo máximo de execução da tarefa i, é o prazo da tarefa i e n é o número de tarefas no sistema. É possível demonstrar matematicamente que esta condição é suficiente para a escalonabilidade de um conjunto de tarefas com o algoritmo de taxa monotônica. Note que esta condição é suficiente, e não necessária. Isto quer dizer que, se a condição for atendida, então certamente o sistema é escalonável. Se a condição não for atendida, o sistema ainda pode ser escalonável, embora não haja como garantir. A curva que limita o valor de utilização tem valor máximo para n = 1 (considerando apenas n inteiro). Neste caso, a condição garante escalabilidade para até 100% de utilização do processador. Para n = 2, o valor máximo de utilização cai para 82,8%. Este valor continua caindo com o aumento do valor de n. Porém, para n grande, a curva tende para uma utilização de cerca de 70%. Outra maneira de verificar a escalabilidade do conjunto de tarefas é através de simulação. Simulando o escalonamento do processo supondo que todas as tarefas chegam ao sistema no mesmo instante (chamado de instante crítico) é possível verificar se um sistema é escalonável, bastando levar a simulação até o final do primeiro ciclo da tarefa de ciclo mais longo. Caso neste intervalo de tempo seja possível realizar o escalonamento, então certamente o sistema é escalonável. Se algum prazo é perdido neste intervalo, então o sistema não pode ser escalonado. Um segundo algoritmo de escalonamento para sistemas de tempo real é o EDF (Earliest Deadline First). O EDF também é um escalonador preemptivo e seu funcionamento é bastante similar ao SJF. Em cada oportunidade de escalonamento, o EDF seleciona o processo (dentre aqueles aptos a executar) cujo prazo está mais próximo atualmente.

3 O teste de escalabilidade do EDF é bem mais simples que o do algoritmo de taxa monotônica: Em outras palavras, um conjunto de tarefas é escalonável utilizando o algoritmo EDF se e somente se a utilização do processador fica abaixo de 100%. Embora o EDF seja capaz de escalonar sistemas que não são escalonáveis pelo algoritmo de taxa monotônica, o segundo é mais utilizado em sistemas mais sensíveis a falhas. Isso ocorre porque o EDF tem uma implementação mais complexa que o taxa monotônica e, portanto, está mais susceptível a erros de programação, além de inserir um overhead maior no sistema. Embora estes dois algoritmos sejam as bases dos escalonadores implementados na maior parte dos sistemas reais, na prática os mecanismos de escalonamento são bem mais complexos. Quando as várias tarefas de tempo real disputam recursos compartilhados a situação fica bem mais complexa, podendo incorrer em um problema conhecido como inversão de prioridade. Além disso, sistemas de tempo real muitas vezes têm tarefas aperiódicas. Neste caso, os escalonadores precisam estar preparados para lidar com esta situação. Estes detalhes, no entanto, estão fora do escopo desta disciplina. 2. Escalonamento no Linux Ao longo dos anos, o Linux teve vários tipos de escalonadores diferentes. Em suas primeiras versões, o Linux empregava um simples escalonador round-robin que não considerava prioridades. Este escalonador servia aos propósitos do SO naquele momento, pois era uma solução bastante simples e rápida. A partir da versão 2.2 do seu kernel, o Linux passou a implementar um escalonador com múltiplas filas, cada uma com uma política diferente. Inicialmente, foram criadas três políticas: a política de tempo real, a política dos processos não-preemptíveis e a política de processos preemptíveis (que não fossem de tempo real). O uso do processador por cada uma destas políticas era controlado por um outro escalonador que somente garantia aos processos de tempo real a maior prioridade no sistema (outros processos só são executados caso não haja processos de tempo real prontos). O escalonador que manipulava os processos preemptíveis que não são de tempo real, porém, continuava adotando uma simples política do tipo roundrobin. Este escalonador passou a sofrer uma série de modificações a partir de então. Na versão 2.4 do kernel, o Linux substituiu o round-robin por um escalonador conhecido como O(n). A cada oportunidade de escalonamento, o escalonador O(n) varre todos os n processos da lista de processos aptos, verificando qual deve ser posto em execução, de acordo com uma função utilidade. Este escalonador, embora resultasse em bom desempenho para vários sistemas, enfrentava problemas de escalabilidade (por precisar varrer toda a lista de processos aptos do sistema).

4 Na versão 2.6, o Linux teve o escalonador O(n) substituído pelo escalonador O(1). A principal diferença entre estes escalonadores está no fato de que o O(1) não precisa varrer toda a lista de processos para tomar as decisões de escalonamento. Ele mantinha várias estruturas de fila (duas para cada processo) em um esquema conhecido como Multilevel Feedback Queue e apenas buscava o primeiro processo apto na estrutura de dados (de mais alta prioridade). O problema deste escalonador, no entanto, era a grande complexidade do seu código fonte, que se tornava cada vez mais difícil de manter. Em 2007, foi criado o escalonador CFS (Completely Fair Scheduler), incorporado inicialmente à versão do Linux. Este escalonador, que hoje é utilizado por padrão na maior parte das distribuições Linux, tem por objetivo dividir de maneira justa o tempo de utilização do processador pelos vários processos. Para isso, os processos aptos a serem executados são ordenados em uma estrutura de dados chamada de árvore vermelho e preto. Esta estrutura de dados tem a propriedade de permitir operações muito eficientes. O escalonador guarda para cada processo uma variável que contabiliza o tempo de espera do processo pelo processador. Enquanto o processo está apto, esperando pelo processador, esta variável é periodicamente incrementada. Quando o processo ganha o processador e começa a executar, a variável começa a ser decrementada. Idealmente, o tempo de espera de todos os processos deve ser bem próximo a 0. A árvore de processos aptos é montada de forma que processos que utilizaram menos o processador fiquem sempre mais à esquerda e mais abaixo. Especificamente, o processo com o maior tempo de espera pelo uso do processador é sempre aquele que está na folha mais à esquerda da árvore. Quando um novo processo chega ao sistema (ou volta, após ter usado o processador ou ter estado bloqueado), este é inserido na árvore em uma posição condizente com seu tempo de espera. O CFS lida ainda com prioridades. A prioridade de um processo é utilizada como um fator de normalização do tempo de espera pelo processador. Quanto mais alta a prioridade, maior é o incremento do tempo de espera quando o processo está fora do processador e menor é o decremento quando este é escalonado. Além de garantir uma certa justiça no uso do processador, este escalonador tem overhead bastante baixo, por utilizar uma estrutura de dados eficiente. 3. Escalonamento no Windows As primeiras versões do Windows (ainda executadas sobre o MS-DOS) não eram multitarefa, nem multiprogramadas. Logo, não era necessária a existência de um escalonador. A partir do Windows 95, o Windows passou a ser um sistema multiprogramado e multitarefa, contando com um escalonador preemptivo bastante simples.

5 As versões do Windows baseadas no Windows NT (o que inclui o Windows XP, Vista e 7) passaram a implementar um escalonador do tipo Multilevel Feedback Queue, com 32 níveis de prioridade. A prioridade 0 é destinada apenas para processos que implementam serviços do SO. As prioridades 1 a 15 são utilizadas por processos normais dos usuários. Finalmente, as prioridades 16 a 31 são utilizadas por processos de tempo real. O usuário especifica uma prioridade estática para o seu processo (uma de 1 a 15), mas o SO pode fazer pequenas alterações nesta prioridade se ele julgar que deve, dadas as características da aplicação (se é interativa ou não, se é CPU Bound ou I/O Bound). O objetivo destas mudanças de prioridade é dar melhor tempo de resposta a programas interativos. A partir do Windows Vista, a maior mudança no escalonador foi a medição da duração de uma fatia de tempo em ciclos de processador e não em tempo de parede. Ao invés de programar uma interrupção para um determinado tempo (entre 10 ms e 15 ms, em geral, no Windows), o Windows Vista monitora quantos ciclos de CPU foram efetivamente executados pelo processo. O problema de se usar o tempo de parede para determinar a fatia de tempo do processo é que interrupções podem ocorrer no meio do slice do processo. Com isso, parte do tempo alocado no slice do processo é utilizado pelos tratadores de interrupção do SO, e não pelo processo em si. Através de um registrador especial existente nos processadores mais modernos, é possível contabilizar exatamente quantos ciclos do processador cada processo utiliza. Por se tratar de um registrador, este valor faz parte do contexto do processo, não sofrendo influência da execução dos tratadores de interrupção.