Análise de Desempenho do Escalonador de Processos de
Feedback em Modo Usuário no Minix em um BeagleBone
Alexandre B. Ferreira1, Bárbara C. M. Lopes1
1
Faculdade de Engenharia da Computação Universidade Federal do Pará – Tucuruí – PA – Brasil
beletti@ufpa.br, babimelopes@gmail.com
Abstract. The present work aims to analyze a feedback process scheduler,
considering version 3.2.1 of Minix running over a BeagleBone. After the implementation, some tests will be done to measure the performance of this scheduler, comparing your execution time with the original one from the operating system.
Resumo. O presente trabalho tem como objetivo analisar um escalonador de
processos de feedback no Minix 3.2.1 executando em um BeagleBone. Após a implementação, serão executados alguns testes para medir o desempenho desse escalonador, comparando o seu tempo de execução com o do escalonador original do sistema operacional.
1. Introdução
Quando considerada a alternância de processos em um sistema operacional, sempre deve ser considerado como essa alternância pode ocorrer. Ao longo dos anos muitos desenvolveram estratégias distintas para lidar com essa questão, sendo que um padrão já conhecido pode ser melhorado. Avalia-se então como o sistema operacional se comporta em situações distintas, como visto nos trabalhos de Con Kolivas (2004, 2007) e de Guerrero et al. (1996).
Na literatura clássica, como por exemplo no livro de Tanenbaum e Bos (2014), são abordadas diversos mecanismos de implementação de escalonadores, sendo que um dos mais utilizados para sistemas operacionais é o modelo Robin Round com Prioridades, como pode ser visto no artigo de Guerrero et al. (1996).
Dificilmente ocorrem grandes modificações nos escalonadores de processos de sistemas operacionais, porém com o trabalho apresentado por Swift (2010), verifica-se a possibilidade de explorar alguns detalhes do comportamento dos processos para tentar ajustar sua prioridade e quantum de forma mais dinâmica e precisa, similar ao que foi proposto por Teller e Seelam (2006), exceto pela questão da método científico empregado no desenvolvimento desse último.
Como o trabalho de Swift (2010) foi o que motivou a melhora do escalonador de processos do sistema operacional e o mesmo foi implementado dentro do Minix 3.1, optou-se por continuar desenvolvendo para o mesmo sistema operacional, porém reescreveu-se o código do escalonador dentro do Minix 3.2.1, pois era a versão atual na época do início deste trabalho e também por trabalhar tanto com arquitetura de processadores x86 de 32 bits, quanto com a arquitetura ARMv7 presente no Beaglebone (Coley, 2012).
Algo que possibilitou maior flexibilidade na codificação do escalonador é o fato de que no Minix 3.2.1 o escalonador de processos encontra-se em modo usuário, como também pode ser visto no trabalho de Swift (2010), seguindo o proposto por Herder et
al. (2006), o que garante a modularidade dos componentes do núcleo do sistema, além
de proporcionar mais segurança ao modelo de micro núcleo do Minix.
O presente trabalho está em andamento, tendo como principal objetivo analisar o aumento do tempo gasto pelo escalonador de feedback no Minix 3.2.1 em relação ao escalonador original, executando em uma arquitetura de processador ARMv7.
O restante desse artigo está organizado da seguinte maneira: Na seção 2 é apresentado o método científico adotado. Na seção 3 são descritos os principais aspectos do escalonador de feedback em modo usuário. Na seção 4 são discutidos os resultados preliminares. Na seção 5 são apresentadas as conclusões.
2. Método Científico
Inicialmente foi obtido o código original do trabalho proposto por Swift (2010), que foi implementado no Minix 3.1, funcionando somente em processadores x86 de 32
bits. O código foi então adaptado para o Minix 3.2.1, pois esse executa em
processadores x86 de 32 bits e também em todas as versões do ARMv7 presentes no Beaglebone, segundo a documentação oficial do Minix (2014).
Para realizar os testes no Beaglebone, escolheu-se o emulador Linaro QEMU, capaz de emular o Beaglebone-xM, executado-o dentro do Windows 8.1, com um processador Intel Core i7, com 8 Gigabytes de memória RAM.
Como poderá ser constatado na seção 3 desse artigo, o escalonador do Minix 3.2.1 executa em espaço de usuário, porém o seu código binário precisa fazer parte da imagem do kernel. Dessa forma foram geradas duas versões distintas do kernel do Minix 3.2.1, uma com o escalonador padrão do Minix e a outra com o escalonador de
feedback. Para os testes com cada escalonador, a máquina foi reiniciada para carregar a
versão adequada do kernel.
Para testar o escalonador foi feito o uso de um script que descompacta uma cópia do CD de instalação do Minix com o utilitário bunzip2. Os tempos medidos utilizam o programa time, seguindo o manual de Kerrisk (2014).
3. Escalonador de Processos em Modo Usuário
O escalonador de processos de um sistema operacional é o responsável pela alternância das muitas aplicações que executam concorrentemente. Ele é quem define a lógica pela qual os processos serão escolhidos para serem executados.
Um fato interessante quando observado o funcionamento do escalonador de processos no Minix, considerando o núcleo do sistema desde a versão 3.1, é que o mesmo encontra-se localizado quase que em sua totalidade em espaço de usuário.
O estudo e a implementação realizada por Swift (2010) teve como objetivo migrar o máximo possível das rotinas do escalonador para o espaço de usuário (user
mode), com o objetivo de deixar o sistema cada vez mais tolerante a falhas e ainda
facilitar a implementação de múltiplos escalonadores de processos em um mesmo sistema operacional (Figura 1).
Figura 1. Escalonador de Processos em Modo Usuário
Durante os estudos e experimentos realizados por Swift (2010), constatou-se que uma parte do escalonador precisaria ficar ainda em modo de núcleo (kernel mode), pois os primeiros processos criados quando o sistema está sendo carregado precisam de algum tipo de gerenciamento inicial, sendo que posteriormente o controle poderia então ser dado ao escalonador em modo usuário.
Outro fato a ser considerado é que o Minix faz uso de troca de mensagens para a comunicação inter processos (IPC) e um escalonador em modo usuário precisa de mais trocas de mensagens para poder realizar os mesmos procedimentos que um escalonador em modo kernel realizaria com um número menor de troca de mensagens, demandando mais tempo, como poderá ser verificado através dos testes da Seção 4.
Considerando que o objetivo do Minix não é o alto desempenho mas sim a alta disponibilidade, como explicado no trabalho de Herder et al. (2006), mover o escalonador para o espaço de usuário é algo atípico porém válido para essa organização de sistema operacional.
3.1. O Escalonador de Processos de Feedback
O escalonador de feedback foi proposto por Swift (2010), tendo sido implementado e testado originalmente no kernel 3.1 do Minix. Com base nesse escalonador, foi implementada uma nova versão para o kernel 3.2.1 do Minix.
A ideia do escalonador de feedback é criar algumas métricas e utilizá-las para tomada de decisão do escalonamento de forma mais precisa. A versão original, utilizada neste trabalho, possui as métricas presentes na Tabela 1.
Tabela 1. Métricas originais do escalonador de feedback
Atributos Descrição
SCHEDULING_ACNT_QUEUE Valor de tempo de CPU "sojourn".
SCHEDULING_ACNT_IPC_SYNC Número de vezes que o processo foi bloqueado em chamadas IPC síncronas. SCHEDULING_ACNT_IPC_ASYN Número de mensagens assíncronas enviadas.
SCHEDULING_ACNT_DEQS Número de vezes que o processo foi retirado da fila.
SCHEDULING_ACNT_PREEMPT Número de vezes que o processo sofreu preempção devido a alternância de um processo com prioridade maior.
SCHEDULING_ACNT_CPU_LOAD Utilização da CPU (0-100) no núcleo em que o processo está alocado. Útil para balancear os processos entre núcleos.
Basicamente o escalonador de feedback faz uso das mensagens de limite de
quantum atingido, enviadas pelo kernel do Minix, anexando as métricas a essas
mensagens para o escalonador em modo usuário poder tomar decisões mais precisas. O escalonador de feedback atual introduziu o conceito de burst e seu valor é definido pela Equação 1.
= ú ℎ (Equação 1) Modo Usuário Modo Kernel Sistema de Arquivos
Driver 1 Driver 2 Driver 3
Escalonador de Processos Gerenciador de
Memória
Relógio Kernel Tarefas de
O valor de burst é utilizado para ajustar a prioridade e o processo, porém cada valor é ajustado de forma distinta. De qualquer forma a Equação 2, que fornece o valor de
O valor de incremento
e o seu valor é discutido no trabalho tipo inteiro (chamado de ajuste processo, definida pela Equação 3
Além disso, o quantum observado na Equação 4.
=
Como o trabalho ainda está em desenvolvimento, não foram feitas alterações nas métricas originais. O ajuste de 20%
Swift (2010).
4. Resultados Preliminares
Conforme mencionado na sdois escalonadores, medindo o tempo de execução de amb vezes (Nogueira e Matias, 2014)
em espaço de kernel e a soma entre os dois
Calculando a média aritmética entre os cinco valores de cada um dos testes, pode-se ter uma melhor ideia
analisar os resultados foram criados alguns gráficos para compará
A Figura 2(a) ilustra o desempenho dos dois escalonadores, considerando o tempo consumido em espaço de us
sistema.
(a)
Figura 2. Tempo gasto em espaço de usuário (a) e em espaço de sistema (b).
A Figura 3 ilustra o desempenho dos dois escalonadores, considerando o tempo real, ou seja, o somatório de todos os tempos
é utilizado para ajustar a prioridade e o quantum processo, porém cada valor é ajustado de forma distinta. De qualquer forma
o valor de ajuste de fila de prioridade.
=
incremento é uma constante definida no código fonte do escalonador
no trabalho de Swift (2010). Obtém-se então um resultado do
ajuste) e com ele pode ser calculada a nova
processo, definida pela Equação 3.
=
quantum do processo também precisa ser ajustado, conforme
∙ ∙ 0,20
trabalho ainda está em desenvolvimento, não foram feitas alterações nas ajuste de 20% da Equação 4 também é discutido no trabalho de
Resultados Preliminares
na seção 2 desse artigo, realizou-se o teste de desempenho dos medindo o tempo de execução de ambos. O teste foi repetido (Nogueira e Matias, 2014), obtendo os tempos de execução em espaço de usuário,
e a soma entre os dois (turnaround).
Calculando a média aritmética entre os cinco valores de cada um dos testes, ideia do desempenho de cada um dos dois escalonadores. Para analisar os resultados foram criados alguns gráficos para compará-los.
ilustra o desempenho dos dois escalonadores, considerando o tempo consumido em espaço de usuário. A Figura 2(b) considera o tempo em espaço de
(b)
. Tempo gasto em espaço de usuário (a) e em espaço de sistema (b).
ilustra o desempenho dos dois escalonadores, considerando o tempo real, ou seja, o somatório de todos os tempos.
quantum de um
processo, porém cada valor é ajustado de forma distinta. De qualquer forma é necessária
(Equação 2)
stante definida no código fonte do escalonador então um resultado do a nova prioridade do
(Equação 3)
do processo também precisa ser ajustado, conforme
(Equação 4)
trabalho ainda está em desenvolvimento, não foram feitas alterações nas discutido no trabalho de
o teste de desempenho dos foi repetido cinco , obtendo os tempos de execução em espaço de usuário,
Calculando a média aritmética entre os cinco valores de cada um dos testes, do desempenho de cada um dos dois escalonadores. Para
ilustra o desempenho dos dois escalonadores, considerando o (b) considera o tempo em espaço de
. Tempo gasto em espaço de usuário (a) e em espaço de sistema (b).
Figura
5. Conclusões
Considerando o mecanismo de IPC do Minix, após a implementação do controle das métricas dentro do escalonador de
processos, um acréscimo de ao escalonador original.
Na próxima etapa deste trabalho
feedback, mensurando o tempo de
desempenho do escalonador de
Referências
Coley, G. (2012) “BeagleBone Rev A6 System Reference Manual beagleboard.org, May.
Guerrero, R., Leguizamon, L., Gallard, R. Alternative Process Schedulers in Minix
Review, Volume 27 Issue 1
Herder, J. N., Bos, H., Gras, B., Homburg, P., Tanenbaum, A. S. Highly Reliable Self Repairing Operating System
Systems Review, Volume 40 Issue 3
Kerrisk, N. (2014) “Linux Users's Manual”, pages/man1/time.1.html
Kolivas, C. (2004) “Staircase Scheduler 2.6.7”,
Kolivas, C. (2007) “RSDL Completely Fair Starvation Free Interactive CPU Scheduler”, http://lwn.net/Articles/224654/
Minix (2014) “Minix3”, http:// Nogueira, P. E., Matias, R. (2014
de Execução de Experimentos Computacionais
on Computing Systems Engineering
IEEE Computer Society
Swift, B. P. (2010) "User Mode Scheduling in MINIX3 Assignment, Vrije University, Amsterdan.
Tanenbaum, A.S., Bos, H. (2014 Teller, P. J., Seelam, S. R
operating system policies 40 Issue 2, pages 83-89,
Figura 3. Tempo real dos dois escalonadores
Considerando o mecanismo de IPC do Minix, após a implementação do controle das métricas dentro do escalonador de feedback, ajustando o quantum e a prioridade dos processos, um acréscimo de somente 0,084% no tempo foi observado em comparação
e trabalho pretende-se fazer um melhor uso das métricas de o tempo de turnaround e throughput e
desempenho do escalonador de feedback entre as plataformas ARMv7 e x86 de 32
BeagleBone Rev A6 System Reference Manual
Guerrero, R., Leguizamon, L., Gallard, R. (1993) "Implementation and Evaluation of Alternative Process Schedulers in Minix", Em ACM SIGOPS Operating Systems
Volume 27 Issue 1, pages 79-100, ACM New York, NY, USA Herder, J. N., Bos, H., Gras, B., Homburg, P., Tanenbaum, A. S. (2006
Highly Reliable Self Repairing Operating System", Em ACM SIGOPS Operating Volume 40 Issue 3, pages 80-89, ACM New York, NY, USA
Kerrisk, N. (2014) “Linux Users's Manual”, http://man7.org/linux/man pages/man1/time.1.html, December.
(2004) “Staircase Scheduler 2.6.7”, http://lwn.net/Articles/87244/
, C. (2007) “RSDL Completely Fair Starvation Free Interactive CPU http://lwn.net/Articles/224654/, March.
http://www.minix3.org, December.
Nogueira, P. E., Matias, R. (2014) "Estudo Quantitativo da Variabilidade nos Tempos de Execução de Experimentos Computacionais", Em Proc. of Brazilian Symposium
on Computing Systems Engineering, Manaus, Brazil, 2014. SBESC., in press of
, Washington, DC, December 2014.
User Mode Scheduling in MINIX3", Individual Programming nt, Vrije University, Amsterdan.
(2014) Modern Operating Systems, Prenticce Hall,4
Seelam, S. R. (2006) "Insights into providing dynamic adaptation of operating system policies". Em ACM SIGOPS Operating Systems Review
89, ACM New York, NY, USA.
Considerando o mecanismo de IPC do Minix, após a implementação do controle das e a prioridade dos foi observado em comparação
se fazer um melhor uso das métricas de comparando o plataformas ARMv7 e x86 de 32 bits.
BeagleBone Rev A6 System Reference Manual”, http://
Implementation and Evaluation of
ACM SIGOPS Operating Systems
ACM New York, NY, USA.
(2006) "Minix3 A
ACM SIGOPS Operating
ACM New York, NY, USA.
http://man7.org/linux/man-http://lwn.net/Articles/87244/, May. , C. (2007) “RSDL Completely Fair Starvation Free Interactive CPU
Estudo Quantitativo da Variabilidade nos Tempos
Proc. of Brazilian Symposium
, 2014. SBESC., in press of
Individual Programming
Prenticce Hall,4th edition. Insights into providing dynamic adaptation of
