Uma Arquitetura Baseada em Eventos para Desenvolvimento de Pol ticas de Escalonamento de Processos

Luciano Porto Barreto Laborat orio de Sistemas Distribu dos - LaSiD o - DCC Departamento de Ci encia da Computac a Universidade Federal da Bahia - UFBA Av. Adhemar de Barros, S/N, Pr edio do CPD, Campus de Ondina Salvador-BA, CEP 40.170-110
lportoba@ufba.br

Resumo. Sistemas baseados em eventos fornecem abstrac o cas que facili es espec tam o desenvolvimento e a manutenc a ticas em diversos dom nios. Embora o de pol as pol ticas de escalonamento de processos sejam geralmente descritas a partir de eventos do sistema (e.g., bloqueio e desbloqueio de processos), a implementac a o de escalonadores reais n ao explora tal modelo. Este artigo apresenta uma arquitetura baseada em eventos voltada ao desenvolvimento de escalonadores de processos e sua implementac a ucleo do Linux. o no n Abstract. Event-based systems provide domain-specic abstractions that help the development and maintenance of policies in several domains. Although process scheduling policies are generally modelled in terms of system events (e.g., process blocking and unblocking), their implementation does not rely on such a model. This paper presents an event-based architecture for the development of process scheduling policies and its implementation in the Linux kernel.

o 1 Introduc a
uma tarefa laboriosa e geralmente restrita a O desenvolvimento de um escalonador de processos e necess especialistas em sistemas operacionais, pois e ario um conhecimento preciso da estrutura e do funcionamento do n ucleo. Por raz oes de desempenho, o desenvolvimento de um escalonador requer a escrita de c odigo otimizado e de baixo n vel, geralmente em C ou Assembly. Mesmo cleo, a exemplo de Chorus [14] e QNX [7] e nos sistemas baseados na arquitetura de micro-nu dif nos sistemas operacionais ditos extens veis como SPIN [4], Vino [15] e Exokernel [9], e cil o de grande parte modicar ou integrar uma nova pol tica de escalonamento. De fato, a validac a freq o das dos trabalhos relacionados ao escalonamento e uentemente efetuada atrav es da simulac a o em sistemas reais. pol ticas ao inv es da an alise de sua implementac a Os escalonadores de processos s ao geralmente descritos de modo informal e incompleto apresentado como um aut na literatura. Tradicionalmente, seu funcionamento e omato de estados nitos na forma de um grafo orientado, no qual os arcos representam o conjunto de eventos do o entre cada estado. A noc o de estado e empregada sistema operacional que disparam a transic a a o (e.g., pronto, bloqueado, em execuc o); para reagrupar processos com mesmo status de execuc a a es de escalonadores n geralmente implementada atrav es de las. Entretanto, as implementac o ao reetem este modelo de eventos. Por exemplo, as las de processos s ao por vezes utilizadas o para reduzir o custo associado a ` para armazenar processos em diferentes estados de execuc a m gest ao dessas las. O escalonador Linux, por exemplo, utiliza a la de processos prontos tamb e o e o processo corrente. Essas para armazenar processos que excederam seu quantum de execuc a o acarretam diferenc o existente e os pr aticas de implementac a as importantes entre a documentac a escalonadores reais empregados pelos sistemas operacionais.

 o de Sistemas baseados em eventos t em sido intensamente explorados para a concepc a o dedicados [4, 11]. O grau de abstrac o ambientes de desenvolvimento e sistemas de execuc a a o mais clara e intuitiva, o que facilita a compreens fornecido por eventos torna a programac a ao o e manutenc o. Apesar dessas vantagens e da estreita dos programas e sua respectiva depurac a a o entre eventos e escalonamento de processos, sistemas baseados em eventos foram timicorrelac a damente utilizados nesse contexto. o de Bossa [2] - um framework baseado em eventos Esse contexto motivou a concepc a composto de uma voltado ao desenvolvimento de pol ticas de escalonamento. Este framework e o dedicada que fornece abstrac es de alto n o de linguagem de programac a o vel para a construc a escalonadores (e.g., las de processos, crit erio de escalonamento, atributos de processos), e uma o de programas escritos nessa linguagem diretaarquitetura de eventos que permite a integrac a o mente no n ucleo do sistema operacional. O framework Bossa foi utilizado na implementac a de pol ticas de escalonamento tradicionais como Rate Monotonic, Earliest Deadline First [12] e o de progresso empregadas no contexto de aplicac es mulLinux; e variantes baseadas na noc a o tim dia [1]. A eci encia dos escalonadores implementados em Bossa foi comprovada atrav es de o programas de benchmark espec cos ao escalonamento de processos e pela an alise da execuc a es reais. At de aplicac o e o presente momento, desconhecemos outras abordagens concretas da o de eventos para a construc o de escalonadores. aplicac a a o no Neste artigo descrevemos a arquitetura de eventos de Bossa e sua implementac a o 2 n ucleo do sistema operacional Linux, sem apresentar aspectos da linguagem Bossa. A sec a descreve os componentes b asicos do modelo de eventos utilizado em Bossa e detalhes de seu de o no Linux s o 3. A sec o 4 descreve brevemente senvolvimento e integrac a ao discutidos na sec a a rea e a sec o 5 conclui o artigo apresentando perspectivas futuras. trabalhos correlatos na a a

2 Escalonamento baseado em eventos

composta por tr A arquitetura de Bossa e es componentes : uma vers ao modicada do n ucleo do o; descritos a seguir. sistema operacional, uma pol tica de escalonamento e um suporte de execuc a Nucleo Bossa. O n ucleo utilizado por Bossa possui caracter sticas adicionais para facilitar o de pol cleo e enriquea integrac a ticas de escalonamento. Mais especicamente, esse nu es de evento associadas ao escalonamento de processos e mecanismos cido com noticac o que permitem congurar e instalar uma nova pol tica de escalonamento. denido por uma pol Pol tica de escalonamento. O comportamento do escalonador e tica es que s de escalonamento. Esta pol tica dene as ac o ao efetuadas pelo escalonador quando da ocorr encia de eventos do n ucleo. Uma pol tica de escalonamento Bossa e es espec implementada a partir de um conjunto de abstrac o cas tais como as las de espera e vari aveis para armazenagem de processos, e tratadores de evento. o. Bossa dene um suporte de execuc o que serve de interface entre Suporte de execuc a a o separa a pol o n ucleo e a pol tica de escalonamento. Esse suporte de execuc a tica de es cleo (e.g., controladores de dispositivos, chamadas calonamento das especicidades do nu respons o de mecanismos de baixo n de sistema). Al em disso, ele e avel pela utilizac a vel o de processos. espec cos ao sistema, a exemplo da comutac a es entre A gura 1 apresenta o funcionamento de Bossa ilustrando o uxo de informac o o. Os pontos de escalonamento no o n ucleo, a pol tica de escalonamento e o suporte de execuc a es de evento enviadas ao suporte de execuc o Bossa (1). n ucleo s ao redenidos como noticac o a o de um evento de escalonamento, o suporte de execuc o repassa o evento a ` pol Na recepc a a tica de escalonamento (2), que por sua vez invoca o tratador de evento correspondente e retorna um o utiliza a informac o de valor indicando o novo estado do escalonador (3). O suporte de execuc a a estado de um escalonador para vericar se ele deve efetuar uma troca de processo. Se o estado

 o do processo corrente, n do escalonador indicar que o escalonador deve continuar a execuc a ao h a o espec o. Se o escalonador indica que o processo ac a ca a ser realizada pelo suporte de execuc a o invoca corrente deve ser suspenso e que um processo pronto est a dispon vel, o suporte de execuc a novamente a pol tica de escalonamento para eleger um novo processo (4,5). Por m, se o estado do escalonador indica que o processo corrente deve ser suspenso e que n ao h a processos prontos, o o despacha o processo idle do nu cleo ap suporte de execuc a os ter interrompido o processo corrente.
Aplicaes

Programa Bossa

1. Eventos

2. Eventos

Interface
Poltica de escalonamento

Componentes do ncleo

Suporte de execuo

3. Estado do escalonador 4. Escolha de processo 5. Novo processo

Compilador / Verificador

Ncleo

global do framework Bossa. Figura 1: Visao

es, detalharemos a implementac o do n Nas pr oximas sec o a ucleo Bossa, de uma pol tica de o. Inicialmente, apresentaremos uma vis escalonamento e do suporte de execuc a ao global de seu o no Linux. funcionamento e, em seguida, descreveremos sua implementac a 2.1 O nucleo Bossa es de eventos referentes ao escalonamento Os componentes do n ucleo Bossa efetuam noticac o o. Para tanto, a arquitetura Bossa disponibiliza eventos de processos para o suporte de execuc a o (process.new) e o t espec cos para sinalizar a criac a ermino (process.end) de processos, tiques de rel ogio (system.clocktick), escolha de um novo processo (bossa.schedule), bloqueio (block) e desbloqueio (unblock) de processos. o de alto n Os eventos de Bossa visam fornecer uma representac a vel dos mecanismos do n ucleo onde esses eventos s ao gerados para facilitar o desenvolvimento de escalonadores. o de processos no Linux pode ser realizada pelas chamadas de sistema Por exemplo, a criac a o de processos corresponde ao evento fork() e clone(). Em Bossa, a funcionalidade de criac a process.new.fork. Da mesma forma, os diversos mecanismos que provocam o bloqueio de um processo correspondem ao evento block. Assim, o programador de uma pol tica que deseja o especicar um tratamento para esses eventos n ao precisa conhecer os detalhes de implementac a do n ucleo. o de eventos mascare a diversidade dos mecanismos do n u cleo associados Embora a noc a ao escalonamento, certas pol ticas precisam associar um comportamento a eventos espec cos. Por exemplo, quando do bloqueio de um processo, a pol tica de escalonamento do Windows NT recalcula a prioridade do processo segundo o tipo de recurso por ele solicitado. Em Bossa, isto requer que o desenvolvedor possa associar tratamentos espec cos para cada um desses eventos de es, organizamos alguns eventos de Bossa em uma hierarquia bloqueio. Para lidar com essas situac o (denotada pelo s mbolo *). Dessa forma, o desenvolvedor pode tratar o caso gen erico de bloqueio o particular, por exemplo, assim que o de processo (block.*), bem como lidar com uma situac a colocado em espera por um recurso de rede (block.net.*). processo e es de evento Noticac o o de evento (e) gerada pelo nu cleo Bossa corresponde a um tipo de dado que Uma noticac a es sobre a classe do evento (e.g., bloqueio, desbloqueio), sobre o processo geracont em informac o destinado dor do evento (chamado de processo gerador) e sobre o processo para o qual o evento e

 o e.target e e.source para (chamado processo destino). Neste artigo, utilizamos a notac a referenciar os processos gerador e destino do evento e, respectivamente. importante notar que os valores de e.target e e.source variam em func o do tipo E a o da passagem de um tique de relo gio do evento. Consideremos dois exemplos. Na noticac a o processo corrente, para o qual o evento e destinado, ao (system.clocktick), e.target e nula pois tal evento n gerado por um processo. No evento passo que a vari avel e.source e ao e o de processo (process.new.fork), o valor de e.source cont o de criac a em a identicac a o do novo do processo pai, gerador desse evento, e o valor de e.target cont em a identicac a processo. 2.2 Pol tica de escalonamento Uma pol tica de escalonamento Bossa especica o comportamento do escalonador quando da o de um evento. A gura 2 apresenta o pseudo-co digo de um escalonador Bossa. Esse recepc a escalonador dene inicialmente os atributos associados a cada processo (e.g., prioridade, deadline), as las de espera e vari aveis utilizadas para armazen a-los. A parte principal do escalonador o handle event). Para encontra-se no c odigo dos tratadores de evento (agrupados na func a tratar um evento, o escalonador deve identicar o evento recebido para, em seguida, disparar a o do tratador correspondente. Como ilustra a gura 2, todos os eventos retornam o novo execuc a estado do escalonador (discutido a seguir).
// Declarac o es : atributos, las de espera int handle_event(event) { // C odigo dos tratadores de evento e c alculo do estado do escalonador switch (event) { case system.clocktick : {...} case unblock.* : {...} case block.* : {...} ... } return scheduler_state; } // func o es auxiliares Figura 2: Pseudo-codigo de um escalonador Bossa.

Estado de um escalonador Um escalonador pode ser considerado como um processo virtual que divide o tempo do processador entre seus processos. Assim como um processo convencional, um escalonador Bossa possui um estado : Scheduler Running, Scheduler Blocked ou Scheduler Ready. Um escalonador est a o. Um escalonador no estado Scheduler Running quando um de seus processos est a em execuc a est a no estado Scheduler Blocked quando nenhum processo est a apto para ser executado. Enm, um escalonador est a no estado Scheduler Ready assim que um dos processos est a pronto para ser executado.
Tratadores de evento es realizadas pelo escalonador quando da recepc o de um Um tratador de evento dene as ac o a o. Por exemplo, em uma pol evento proveniente do suporte de execuc a tica de escalonamento de tempo compartilhado, o tratador do evento system.clocktick deve normalmente vericar o excedeu seu quantum para saber se e necess se o processo em execuc a ario interromp e-lo. Da mesma forma, o tratador de um evento de bloqueio de processo deve colocar o processo corrente em uma la de processos bloqueados. Ao m de cada tratador de evento, a pol tica deve calcular o. o novo estado do escalonador para reenvi a-lo ao suporte de execuc a o 2.3 Suporte de execuc a o serve de intermedi O suporte de execuc a ario entre o n ucleo e a pol tica de escalonamento. Ele respons tamb em e avel pela mudanc a de contexto entre processos e utiliza os mecanismos do

 o mant es tais como n ucleo destinados a este prop osito. O suporte de execuc a em certas informac o ltimo processo a ser executado, e o escalonador instalado no sistema. o processo corrente, o u importante frisar que o suporte de execuc o desconhece os atributos dos processos ou E a as las de espera utilizadas pela pol tica de escalonamento. De fato, ele tem acesso somente aos atributos de sistema associados ao processo (e.g., pid, gid, criador do processo). Mesmo o da pol o pode ignorando os detalhes de implementac a tica de escalonamento, o suporte de execuc a descobrir se esta pol tica deve escolher um novo processo atrav es da an alise do valor do estado o e a pol do escalonador. Esta independ encia entre o suporte de execuc a tica de escalonamento permite que o escalonador seja facilmente substitu vel ou testado fora do n ucleo.

o no Linux 3 Implementac a
o anterior apresentamos o modelo conceitual de uma arquitetura para o desenvolvimento Na sec a o, apresentamos a de escalonadores de processo modulares e baseados em eventos. Nesta sec a o implementac ao dessa arquitetura no n ucleo do Linux (vers oes 2.2.16 e 2.4.18) atrav es da descric a es efetuadas nesse n o do suporte de execuc o e trechos ilusdas modicac o ucleo, a implementac a a es emtrativos de uma pol tica de escalonamento. Al em disso, mostramos os problemas e soluc o pregadas para compatibilizar o modelo de eventos de Bossa com as especicidades de funcionamento do n ucleo do Linux. 3.1 O nucleo Bossa/Linux o das noticac es de eventos demandou a modicac o de diversas partes do n A introduc a o a ucleo Linux tais como os controladores de dispositivos, os sistemas de arquivos, a camada de rede, as cleo (i.e., os daemons). A t o, a chamadas de sistema e alguns processos do nu tulo de ilustrac a es de eventos introduzidas em cada direto rio da raiz da tabela 1 apresenta o n umero de noticac o o do n o da vers distribuic a ucleo na implementac a ao 2.4.18 do n ucleo Bossa/Linux.
Diret orio drivers net fs kernel mm arch include lib ipc init
Sub-sistemas Controladores de dispositivos Rede Sistema de arquivos o, interrupc es, timers, etc. Sincronizac a o Gerenciamento de mem oria diversos diversos diversos o entre processos Comunicac a o do sistema Inicializac a
Eventos 126 44 54 24 24 14 11 9 6 1
Arquivos 33 16 19 8 7 4 6 2 2 1

Tabela 1: Numero de noticac oes de evento por diretorio do nucleo Bossa/Linux.

inserido em cada local do n Um evento Bossa e ucleo onde um componente do sistema efetua uma chamada ao escalonador. No Linux, esse ponto de escalonamento caracteriza-se por ` func o schedule() ou de modo indireto atrav ` func o uma chamada a a es de uma chamada a a schedule timeout(). Tais chamadas s ao geralmente seguidas ou precedidas de uma mudanc a no estado do processo. No n ucleo do Linux, a mudanc a de estado de um processo consiste em modicar o campo state da estrutura task struct associado ao processo. De fato, a mudanc a de estado pode ser realizada de diversas maneiras segundo a vontade do programador e pode ainda variar de uma vers ao do n ucleo a outra.
es de evento, foi preciso identicar todas as partes do nu cleo Para introduzir as noticac o ` func o schedule(). Em seguida, para caracteonde havia uma chamada direta ou indireta a a rizar a natureza do evento (e.g., bloqueio, desbloqueio), foi necess ario levar em conta o contexto da chamada ao escalonador. Para tanto, analisamos se havia mudanc a no estado do processo (do s a chamada a ` func o schedule(). No Linux, o estado de ponto de vista do Linux) antes ou apo a

um processo pode assumir os valores TASK INTERRUPTIBLE, TASK UNINTERRUPTIBLE e TASK STOPPED indicando que o processo corrente deve ser bloqueado. Assim, uma chamada ` func o schedule() precedida de tais mudanc a a as de estado caracteriza um evento de blo o apresentando a noticac o do evento de bloqueio queio em Bossa. A gura 3 ilustra esta situac a a SIGNAL PFTRACED (realizada pela macro BOSSA BLOCK). Esse evento e produzido assim que enviado para interromper a execuc o de um processo. um sinal ptrace e a
int do_signal(struct pt_regs *regs, sigset_t *oldset) { // arch/i386/kernel/signal.c ... current->state = TASK_STOPPED; notify_parent(current, SIGCHLD); BOSSA_BLOCK(SIGNAL_PFTRACED,current); // noticac a o de evento schedule(); } de um evento de bloqueio quando do envio do sinal ptrace. Figura 3: Noticac ao

cleo utiliza a func o bossa Assim que o evento deve ser enviado ao escalonador, o n u a o s notify event, apresentada na gura 4. Os argumentos desta func a ao o nome do evento, o o agrupa as informac es associadas ao evento e processo destino e gerador do evento. Esta func a o o handle event) para disparar a execuc o do chama o ponto de entrada do escalonador (func a a tratador de evento correspondente.
inline int bossa_notify_event // kernel/bossa.c (int event_type, struct bossa_struct * target, struct bossa_struct * source){ e.type = event_type; e.source = source; e.target = target; ... // send event to the scheduler root_s_state = root_scheduler.ops-> handle event(&e,x,e.target->next_list.next); }
de evento Bossa em Linux. Figura 4: Noticac ao

o 3.2 Suporte de execuc a o foi concebido para permitir a integrac o de escalonadores ao n O suporte de execuc a a ucleo de o schedule() do Linux, maneira simples e modular. Para isso, substitu mos o c odigo da func a o Bossa. O suporte de execuc o mant tornando-a o ponto de entrada do suporte de execuc a a em ltimo processo a ser executado ainda vari aveis que armazenam o processo corrente (running), o u cleo (root scheduler). (old running), e o escalonador instalado no nu
o Bossa. InicialA gura 5 apresenta um trecho da parte principal do suporte de execuc a es para poder manipular mente, utilizamos um lock do n ucleo (linha 3) que bloqueia as interrupc o o e invocar a pol as vari aveis do suporte de execuc a tica de escalonamento de modo seguro (i.e., cleo). Em seguida, noticamos o evento ao essem a interfer encia de outros componentes do nu calonador (linha 5) se a vari avel running->deferred n ao estiver vazia e o processo corrente n ao for o processo idle (rts idle process). A vari avel running->deferred cont em o do u ltimo evento noticado pelo n a identicac a ucleo. Esta vari avel pode estar vazia caso a o do evento armazenada nesta vari noticac a avel tenha sido anulada por outro evento antes da cha o. Por exemplo, um evento de bloqueio seguido do evento desbloqueio mada ao suporte de execuc a o ao escalonador. correspondente n ao gera alguma noticac a
o verica em seguida o estado do escalonador conforme apresenO suporte de execuc a o 2.2. Se o escalonador encontra-se no estado Scheduler Ready (linha 9), um novo tado na sec a o invoca a func o do schedule do processo deve ser escolhido. Para isso, o suporte de execuc a a escalonador (linha 10), que implementa o tratador do evento bossa.schedule. Um escalona ncia, o suporte de dor no estado Scheduler Blocked indica que o mesmo est a inativo e, em conseq ue o despacha o processo idle sem a intervenc o da pol execuc a a tica de escalonamento (linha 13). Em o verica se o processo escolhido e diferente do processo corrente. seguida, o suporte de execuc a o chama a func o switch to() (linha 20) do nu cleo Linux Neste caso, o suporte de execuc a a

(1) asmlinkage void schedule(void) { // kernel/sched.c ... (2) need_resched_back: ... (3) spin_lock_irq(&bossa_scheduler_lock); // get global kernel lock (4) if (running != &rts_idle_process && running->deferred) { (5) bossa notify event(running->deferred,running,NULL); // notify event (6) running->deferred = NULL; (7) } (8) old_running = running; (9) if (root_s_state == SCHEDULER_READY) { // a new process must be elected (10) root_s_state = root_scheduler.ops-> do schedule(); (11) } (12) if (root_s_state == SCHEDULER_BLOCKED) (13) running = &rts_idle_process; // dispatch idle process (14) spin_unlock_irq(&bossa_scheduler_lock); // release kernel lock (15) if (running == old_running) // no process change (16) goto outbossa; (17) ... // prepare for context switch (18) prev = old_running->attr; (19) next = running->attr; (20) switch to(prev, next, prev); // context switch (21) outbossa: (22) if (root_s_state == SCHEDULER_READY) {// do it again if scheduler state has changed (23) goto need_resched_back; (24) } (25) return; }
Bossa em Linux. Figura 5: Trecho do suporte de execuc ao

aquele que se que efetua a mudanc a de contexto. Se o processo escolhido pelo escalonador e o, nenhuma mudanc realizada. Por m, vericamos se houve encontra em execuc a a de contexto e um mudanc a de estado do escalonador para o estado Scheduler Ready (linha 22). Tal mudanc a es, que podem gerar eventos, estiverem habilitadas. de estado pode se produzir caso as interrupc o o. Neste caso, retorna-se ao in cio do tratamento do suporte de execuc a
3.3 Pol tica de escalonamento o de uma pol o de atributos de processo, A implementac a tica de escalonamento consiste na denic a las de espera e vari aveis, c odigo dos tratadores de evento (incluindo o c alculo do estado do importante frisar que os trechos de co es auxiliares. E digo descritos nessa escalonador), e func o o s sec a ao automaticamente gerados pelo compilador Bossa (gura 1). Portanto, o programador o de baixo n es n ao deve se preocupar com detalhes de implementac a vel (ver [3] para informac o adicionais sobre a linguagem Bossa). Atributos de processo o do n O m etodo mais utilizado para adicionar atributos ao contexto de execuc a ucleo Linux consiste em incluir novos campos da pol tica diretamente na estrutura task struct. Em Bossa, os atributos de processo s ao introduzidos na estrutura bossa struct. O campo attr dessa ` pol estrutura permite a tica o acesso aos atributos de processo do Linux (denidos na estrutura task struct). Adicionamos ainda no nal da estrutura task struct o atributo bossa (de o o acesso aos campos denidos por tipo bossa struct) que permite ao suporte de execuc a uma pol tica Bossa.
Filas de espera e vari aveis Em Bossa, as las de espera s ao implementadas como listas encadeadas contendo estruturas de es tipo bossa struct. Para facilitar a gest ao das las de espera e vari aveis, Bossa fornece func o ria que utilizam essas estruturas e func es para espec cas para alocar e liberar blocos de memo o mover um processo de um estado para outro. Para efetuar uma mudanc a de estado, denimos um

 es que recebem como par conjunto de func o ametros a la de espera ou a vari avel de origem e a la o move proc queue move o conteu de espera ou a vari avel de destino. Por exemplo, a func a do o move queue proc realiza o de uma vari avel para uma la de espera ao passo que a func a tratamento inverso.
Tratadores de evento o descreve a implementac o dos tratadores de evento em Bossa. A gura 6 apresenta Esta sec a a o handle event) e o tratamento efetuado o ponto de entrada de um escalonador Bossa (func a pelo evento de bloqueio. O tratador de evento block.* move o processo corrente (running 0) para a la de espera de processos bloqueados (blocked) e, em seguida, calcula o novo estado o empty queue retorna o valor verdadeiro caso a la de espera esteja do escalonador1 . A func a vazia e falso no caso contr ario.
int handle_event(struct event_struct *e,...) { switch (event_mask0(e->type)) { case EVENT_BLOCK: { move_proc_queue(running_0, &blocked); if (empty_queue(&ready)) { // no ready process return SCHEDULER_BLOCKED; } else { return SCHEDULER_READY; } } ... } Figura 6: Ponto de entrada de um escalonador Bossa.

o do schedule que implementa o tratador de evento A gura 7 apresenta a func a o select() (espec ` pol bossa.schedule. Em primeiro lugar, a func a ca a tica de esca invocada para escolher um novo processo consultando a la de processos prontos lonamento) e ent ready. O processo escolhido e ao colocado na vari avel local running 0 e na vari avel do utilizada pelo suporte de execuc o para n ucleo running (importada pelo escalonador), que e a efetuar uma mudanc a de contexto.
int do_schedule (void) { struct bossa_struct * new = select(&ready); // select a new process move_queue_proc(new, running_0); // update Bossa running process running = running_0; // update run-time system running process } return SCHEDULER RUNNING; // return scheduler state, always running in this case }
e despacho de um processo em Bossa. Figura 7: Selec ao

o da implementac o do modelo de eventos para o Linux 3.4 Adaptac a a o das pol teses Os testes de execuc a ticas de escalonamento Bossa mostraram que algumas das hip o relativas aos eventos estavam incorretas. Por exemplo, no tratador de evento de bloqueio (block), o o processo a ser bloqueado (e.target) estava por vezes na la de processos prontos e n a o na vari avel que armazena o processo corrente (running). Isto provocava erros de execuc a assim que o tratador tentava colocar esse processo na la de processos bloqueados. Tais erros de o eram decorrentes da interfer es dos tratadores de evento (i.e., uma execuc a encia entre as execuc o ncia de tratamentos de eventos antes da intervenc o do suporte de execuc o). No evento de seq ue a a o precedente do tratador de tique de bloqueio apresentado, isto ocorre, por exemplo, se a execuc a rel ogio (system.clocktick) colocar o processo corrente (e.target) na la de processos prontos quando do t ermino de seu quantum. o dos tratadores de evento pode ocorrer porque Esse tipo de interfer encia entre a execuc a gio e o desbloqueio de um processo) s alguns eventos de Bossa (e.g., tique de relo ao disparados
1

Note que esse tratador de evento nunca deve retornar o estado Scheduler Running.

 o dos bottom halves do n a partir da execuc a ucleo. No Linux, como em diversos sistemas opera es de hardware e efetuado inicialmente por um top half, que e cionais, o tratamento de interrupc o o e postergada. Ap executado imediatamente e, em seguida, por um bottom half, cuja execuc a os o de todos os bottom halves que foram postergados. Assim, certo tempo, o n ucleo dispara a execuc a e ncia de eventos gerados pelos bottom halves antes que um escalonador Bossa pode tratar uma sequ o utilizado o estado do escalonador seja considerado para atualizar o valor do processo em execuc a o de um escalonador, foi necess por Bossa. Para eliminar esses erros na implementac a ario introdu es. Esse c zir c odigo adicional na pol tica para tratar essas situac o odigo adicional verica o estado o da linatual do processo antes de mov e-lo para uma la de espera ou uma vari avel. A utilizac a digo, j efetuado automaticamente guagem Bossa dispensa a escrita desse co a que esse tratamento e pelo compilador.

4 Trabalhos correlatos
cleo do sistema opeEscalonadores de processos s ao geralmente implementados diretamente no nu ` implementac o de infraestruturas de escalonaracional. Existem algumas propostas voltadas a a mento, mas estas n ao exploram a expressividade do modelo de eventos associado ao escalonamento de processos. Ford e Susarla [6] propuseram uma plataforma voltada ao desenvolvimento de escalonadores hier arquicos nos quais um proocesso se comporta como um escalonador atrav es o de seu tempo de execuc o a outros processos. Vassal [5] e outro exemplo de infrada doac a a estrutura que permite a carga din amica de escalonadores no n ucleo do Windows NT. Regehr et al. [13] propuseram um modelo baseado em uma biblioteca espec ca e um protocolo que dene o de um escalonador. O programador utiliza esses dois componentes para escrever uma a execuc a pol tica de escalonamento. o de eventos para o desenvolvimento de sistemas Algumas propostas utilizam a abstrac a o de componentes do n operacionais. SPIN [4] permite a especializac a ucleo atrav es da implementa o de tratadores de eventos escritos em Modula-3. Entretanto, em SPIN n poss c a ao e vel utilizar cleo. TinyOS [8] e um sistema operacional voltado para eventos para substituir o escalonador do nu o entre tarefas e os associa a equipasistemas embarcados que utiliza eventos para a comunicac a o de mentos tais como sensores e transdutores. A linguagem HIPEC [11] permite a implementac a o de p o de tratadores a eventos espec pol ticas de substituic a agina atrav es da associac a cos, como o de eventos em sistemas falta de p agina. Essas propostas demonstram a viabilidade da utilizac a o na concepc o de escalonadores de processos. operacionais, mas n ao abordam sua aplicac a a

5 Conclus oes
o de escaNeste artigo apresentamos uma arquitetura baseada em eventos para a implementac a o no n lonadores de processos e sua integrac a ucleo do Linux. Essa arquitetura permite a escrita cleo a partir de de pol ticas de escalonamento modulares e independentes dos mecanismos do n u o das abstrac es foreventos que capturam conceitos do dom nio. Este modelo balisou a denic a o o do c `s necidas pela linguagem Bossa, cujo compilador automatiza a gerac a odigo C referente a o de escalonadores [10]. pol ticas de escalonamento e proporciona a vericac a A independ encia entre uma pol tica Bossa e o n ucleo aprimora a portabilidade dos esca o e teste fora do n es). A noc o lonadores e viabiliza sua execuc a ucleo (e.g., atrav es de simulac o a o de infraestruturas hier de estado, associado a um escalonador, propicia a construc a arquicas de escalonamento, nas quais escalonadores com caracter sticas espec cas podem ser empregados de ` s aplicac es. Al modo a prover diferentes garantias a o em disso, toda funcionalidade de um escalona nico lugar, o que facilita a manutenc o e compreens dor concentra-se em um u a ao do funcionamento da pol tica de escalonamento. o da genericidade do modelo de eventos requer a integrac o da arquitetura A validac a a Bossa em outros sistemas operacionais. Estudos preliminares foram feitos em BSD e atualmente existem trabalhos voltados ao Windows NT e variantes do Linux dedicadas aos sistemas embarcados.

Disponibilidade o do n A distribuic a ucleo Bossa/Linux, o compilador/vericador e exemplos de pol ticas de escalonamento encontram-se publicamente dispon veis em http://www.emn.fr/x-info/bossa

Refer encias
es multim o [1] L. P. Barreto. Atendendo aos requisitos de QoS de aplicac o dia atrav es da especializac a de servic os do sistema operacional. In IX Simp osio Brasileiro de Sistemas Multim dia e Web (Webm dia2003), pages 2134, November 2003. dholt. Programming OS schedulers with domain-specic [2] L. P. Barreto, R. Douence, G. Muller, and M. Su languages and aspects: New approaches for OS kernel engineering. In Proceedings of the 1st Workshop on Aspects, Components, and Patterns for Infrastructure Software, pages 16, April 2002. [3] L. P. Barreto and G. Muller. Bossa: a language-based approach to the design of real-time schedulers. In Proceedings of the 10th International Conference on Real-Time Systems (RTS2002), pages 1931, Paris, France, March 2002. [4] B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, safety and performance in the SPIN operating system. In Proceedings of the 15th ACM Symposium on Operating Systems Principles (SOSP95), pages 267284, December 1997. [5] G. M. Candea and M. B. Jones. Vassal: Loadable scheduler support for multi-policy scheduling. In Proceedings of the 2nd USENIX Windows NT Symposium, pages 157166, Berkeley, CA, August 1998. [6] B. Ford and S. Susarla. CPU inheritance scheduling. In Proceedings of the 2nd USENIX Symposium on Operating Systems Design and Implementation (OSDI96), pages 91105, Berkeley, CA, USA, October 1996. [7] D. Hildebrand. An architectural overview of QNX. In Proceedings of the USENIX Workshop on MicroKernels and Other Kernel Architectures, pages 113126, Seattle, WA, USA, April 1992. [8] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister. System architecture directions for network sensors. In Proceedings of the International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS2000), pages 93104, October 2000. o, R. Hunt, D. Mazi` [9] M. F. Kaashoek, D. R. Engler, G. R. Ganger, H. Bricen eres, T. Pinckney, R. Grimm, J. Jannotti, and K. Mackenzie. Application performance and exibility on exokernel systems. In Proceedings of the 16th ACM Symposium on Operating Systems Principles (SOSP97), pages 5265, October 1997. [10] J. Lawall, G. Muller, and L. P. Barreto. Capturing OS expertise in a modular type system: the Bossa experience. In Proceedings of the ACM SIGOPS European Workshop 2002 (EW2002), pages 5461, Saint-Emillion, France, September 2002. [11] C. H. Lee, M. C. Chen, and R. C. Chang. HiPEC: High performance external virtual memory caching. In Proceedings of the 1st USENIX Symposium on Operating Systems Design and Implementation (OSDI94), pages 153164, Berkeley, CA, USA, November 1994. [12] C. L. Liu and J. W. Layland. Scheduling algorithms for multiprogramming in a hard-real-time environment. Journal of the ACM, 20(1):4661, January 1973. [13] J. Regehr and J. A. Stankovic. Augmented CPU reservations: towards predictable execution on generalpurpose operating systems. In Proceedings of the 7th Real-Time Technology and Applications Symposium (RTAS2001), Taipei, Taiwan, May 2001. [14] M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the Chorus distributed operating system. In Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures, pages 3970, Seattle, WA, USA, April 1992. [15] M. I. Seltzer, Y. Endo, C. Small, and K. A. Smith. Dealing with disaster: Surviving misbehaved kernel extensions. In Proceedings of the 2nd USENIX Symposium on Operating Systems Design and Implementation (OSDI96), pages 213227, Berkeley, CA, USA, October 1996.