=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-[07]-=[Algoritmo de escalonamento: Kernel 2.4 Versus 2.6]=- =-|Felipe Goldstein|-=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
–=[ Introdução
O Algoritmo de escalonamento é o coração de um Kernel. Existem muitos algoritmos e a eficiência de cada um deles depende do tipo de aplicação que será executada. O Linux, por ser voltado para o computador pessoal, executa em sua maioria, tarefas que interagem com o usuário. Portanto o algoritmo volta-se principalmente para sistemas interativos. Aqui, discutirei em linhas gerais, o funcionamento do algoritmo de escalonamento do kernel 2.4 e suas desvantagens em relação ao do kernel 2.6.
--=[ Kernel 2.4
--=--=[ Breve descrição do funcionamento do algoritmo de escalonamento
O escalonador do Linux divide o tempo de CPU em Eras (epochs). Em cada Era, cada processo tem um time-quantum que especifica o tempo que o processo vai adquirir de CPU durante a Era atual. Quando o time-quantum de um processo acaba, o escalonador é chamado e outro processo começa a rodar.
Uma Era termina quando todos os time-quantum dos processos ativos acabam. Então a lista ligada dos processos é completamente varrida, e para cada processo, é calculado uma nova prioridade e um novo time-quantum. Por este motivo, o algoritmo de escalonamento do kernel 2.4 tem a ordem de O(n) no número de processos ativos. O fator linear do algoritmo vem diretamente do fato de que o acesso à lista ligada é linear, e também da necessidade de se recalcular a prioridade de cada processo entre cada mudança de Era, porém como veremos no kernel 2.6 isto pode ser feito no momento em que se insere o processo na lista.
Os processos ativos dividem-se em duas listas ligadas usadas pelo escalonador. Uma guarda os processos que ainda não extinguiram todo o seu time-quantum designado para a Era atual e estão esperando para serem escalonados, chamada run-queue enquanto a outra guarda os processos que já extinguiram o seu time-quantum e estão esperando para serem escalonados na próxima era, chamada expired-queue.
--=--=[ Tipos de Processos
Existem 2 tipos básicos de processos: Processos de Tempo Real e os processos convencionais. Os processos de Tempo Real são processos que requerem respostas em tempos determinados. Para isso eles precisam de um maior determinismo do sistema e portanto recebem maior prioridade. Estes tipos de processos recebem uma prioridade que é sempre maior que a dos outros processos convencionais e esta prioridade não muda depois que o processo começa a rodar.
Os processos convencionais recebem uma prioridade que muda conforme a necessidade e no caso do kernel 2.4, basicamente a prioridade muda conforme a quantidade de time-quantum não usada pelo processo em seu último escalonamento, o que faz com que processos IO-Boud recebam maior prioridade (pois este tipo de processo deixa sempre sobrando algum time-quantum quando vai dormir esperando um evento de IO).
--=--=[ Quem deve executar primeiro ?
Uma das principais tarefas do escalonador é fazer a escolha dentre os processos na lista run-queue de qual processo executar primeiro. A escolha é feita pegando da lista run-queue o processo com o maior fator Goodness que é calculado da seguinte maneira:
- Goodness = 0 Se o processo acabou o seu time-quantum. A menos que este processo seja o primeiro processo na lista run-queue e todos os outros processos tenham também acabado seu time-quantum , este processo não será selecionado agora.
- 0 < Goodness < 1000 Se o processo eh convencional e ainda não acabou com seu time-quantum, Goodness é a soma da prioridade do processo com o que resta do seu time-quantum somado com 1.
- Goodness >= 1000 Se o processo é de Tempo Real, seu Goodness é a soma de 1000 com sua prioridade.
Perceba que para fazer esta escolha, todos os processos são percorridos e é calculado o fator Goodness de cada um, o que também implica uma ordem de O(n) ao algoritmo de escalonamento.
--=--=[ Sistemas Multiprocessados
Além da escolha de qual processo rodar primeiro, o escalonador deve escolher também (num sistema multiprocessado) em qual CPU o processo vai rodar. Para melhor utilizar a memória Cache, o kernel 2.4 tenta escolher a CPU no qual o processo já estava rodando. Mas isso pode causar um overload de uma CPU enquanto outras estão ociosas. Então essa escolha é feita usando um fator que leva em conta o tamanho da memória cache do processador e sua frequência. Baseado nesse fator o escalonador decide se vale ou não a pena colocar o processo no mesmo processador. Porém ainda assim, no Kernel 2.4, existe uma situação em que um processo pode ficar 'pulando' de uma CPU para outra constantemente, desperdiçando a memória cache. Este já era um bug conhecido a tempos.
--=--=[ Performance do Kernel 2.4: Desvantagens
- O Algoritmo não é escalável: Conforme aumenta o número de processos ativos, aumenta o overhead no escalonamento. O kernel leva mais tempo pra decidir qual processo rodar, diminuindo o desempenho do sistema.
- Estratégia adotada para processos do tipo IO-Bound não é ótima: Dar preferência aos processos do tipo IO-Bound é uma boa estratégia, mas ela não é perfeita. Imagine que você tenha um processo rodando em background como um banco de dados que a todo momento precisa ler dados do HD, porém ele não precisa ter um tempo de resposta rápido. Com este algoritmo, este tipo de processo vai levar vantagem sobre os outros que não são IO-Bound. Outro problema acontece quando um processo que é CPU-Bound precisa também interagir rapidamente com o usuário, este tipo de processo vai ter menos prioridade por ser CPU-Bound.
- Kernel não é preemptivo: No kernel 2.4 e anteriores, para cada operação de escalonamento e context-switch um mutex-lock global precisa ser adquirido antes de entrar na seção crítica do código. Esta seção crítica é na verdade o código completo do escalonador. Assim, num sistema multiprocessado, apenas um processador podia executar o escalonador por vez.
O mutex-lock global impede que dois ou mais processadores executem o escalonador ao mesmo tempo e isso pode representar perda de tempo de processamento, pois os processadores que estão tentando adquirir o mutex vão ter que esperar até o mutex ser liberado. Além disso, durante a execução do escalonador as interrupções são desligadas, e portanto o kernel não é preemptivo. Durante uma chamada de sistema, o código executado no espaço de kernel não pode ser interrompido. Por exemplo, por um processo de alta prioridade (pode ser de Tempo Real) que acabou de acordar e precisa executar na frente de qualquer outro tipo de processamento.
Tudo isso traz péssimas implicações para processos de Tempo Real, pois diminui o determinismo da prioridade de execução de um processo de Tempo Real.
--=[ Kernel 2.6 - Mudanças
--=--=[ Objetivos
Ao se projetar um novo escalonador para o kernel do linux, mantendo as boas características que o kernel 2.4 trazia e adicionando novas e interessantes, os objetivos principais foram os seguintes:
- Boa performance de interatividade, mesmo durante uma sobrecarga de uso de CPU: Se o usuário clica então o sistema deve reagir instantaneamente e executar a tarefa do usuário de forma suave.
- Justiça: Nenhum processo deixa de receber ao menos um pequeno pedaço de tempo da CPU e nenhum processo recebe injustamente um grande pedaço de tempo da CPU. Respeitando as prioridades de cada processo.
- Prioridades: Tarefas menos importantes recebem prioridades menores, tarefas mais importantes recebem prioridades altas.
- Eficiência em ambiente multiprocessado: Nenhuma CPU deve ficar ociosa se existe trabalho a fazer.
- Afinidade de CPU em ambiente multiprocessado: Processos que rodaram numa CPU têm afinidade a ela, e assim que possível, permanecer executando na CPU em que já foi executada. Nenhum processo deve ficar trocando de CPU muito frequentemente.
As novas características que chamam mais atenção são as seguintes:
- Escalonamento completo usando um algoritmo O(1): Sistema muito mais escalável. O número de processos executando não afeta o desempenho do kernel.
- Kernel Preemptivo: Escalabilidade perfeita num ambiente multiprocessado. Não existe mais nenhum mutex-lock global para proteger a área de código do escalonador. Existe agora 1 lista de processos ativos (run-queue) por CPU, permitindo o acesso em paralelo às run-queues sem a necessidade de mutex.
- Escalonamento tipo Batch: Uma grande porção dos processos CPU-Bound se beneficiam da maneira Batch de escalonamento, onde os time-quantum são grandes e os processos são escalonados por round-robin. O novo escalonador designa este tipo de escalonamento (Batch) para os processos com baixa prioridade, e a nova política de prioridade dinâmica designa menores prioridades quanto mais CPU-Bound for o processo.
- Sistema mais confiável para processos Real Time: O fato do kernel ser Preemptivo e o algoritmo de escalonamento ser O(1) melhora o comporta mento do sistema em relação à dar prioridade às tarefas Real Time, pois agora uma chamada de sistema feita por uma tarefa de prioridade menor pode ser interrompida por uma tarefa de maior prioridade para que ela entre em execução imediatamente.
--=--=[ Vetor de Prioridades
Ao invés de usar só uma lista ligada gigante com todos os processos ativos, foi usado uma outra abordagem na qual temos um vetor de tamanho fixo cujo tamanho é o número de níveis de prioridades. Cada elemento do vetor aponta para uma lista ligada de processos que tem a mesma prioridade.
Essa é a estrutura básica do novo escalonador: A lista run-queue, agora é um vetor de prioridades ordenado e cada CPU têm sua própria run-queue. O vetor de run-queue contém todas as tarefas que têm afinidade com a CPU e ainda têm time-quantum para executar, enquanto o vetor de expired-queue contêm as tarefas que tem afinidade com a CPU e que expiraram seu time-quantum, de maneira que este vetor expired-queue (assim como o run-queue) também é mantido ordenado.
A estrutura do array de prioridades é descrita como:
struct prio_array {
int nr_active; /* number of tasks */
unsigned long bitmap[BITMAP_SIZE]; /* priority bitmap */
struct list_head queue[MAX_PRIO]; /* priority queues */
};
MAX_PRIO é número de níveis de prioridades do sistema. Para cada prioridade é mantida uma lista ligada dos processos que estão naquela prioridade. O escalonador escolhe para executar primeiro a lista dos processos no maior nível de prioridade e executa-os em Round-Robin.
Existe um número fixo de níveis de prioridades, e para escolher um novo processo basta pegar o próximo elemento do vetor de prioridades, portanto, o algoritmo neste caso é O(1), pois temos um tempo constante executado em cada escolha de qual processo executar.
--=--=[ Recalculando os time-quantum
No 2.4, cada vez que terminava uma Era, percorria-se todos os processos recalculando os time-quantum de cada um. No kernel 2.6, o calculo do time-quantum ocorre quando o processo termina todo seu time-quantum da Era atual. Assim, antes de ser passado para o vetor de expired-queue, seu time-quantum e também sua prioridade são recalculados. O vetor de expired-queue é mantido ordenado e contém os processo com os time-quantum já calculados da próxima Era. Quando a Era atual termina, basta trocar os ponteiros do vetor de run-queue por expired-queue e o novo vetor de processos ativos está pronto para ser executado.
A abordagem do kernel 2.6 é uma mistura de lista de prioridades com escalonamento por Round-Robin. Os processos de uma mesma prioridade são escalonados por Round-Robin, mas as prioridades maiores são escalonadas primeiro.
--=--=[ Resposta Rápida
Uma das coisas que mais deixam os usuários do sistema irritados, é a demora no tempo de resposta de um comando. No kernel 2.6 este problema é evitado da seguinte maneira: ao invés de aumentar a prioridade de processos IO-Bound, diminui-se a prioridade dos processos que querem consumir muito tempo de CPU quando tempo de CPU está escasso.
--=[ Conclusão
Essas foram as principais mudanças do kernel 2.4 para o 2.6. O Linux sempre foi um sistema operacional voltado para o usuário de Computador Pessoal e por isso conceitos como processamento de tarefas de Tempo Real, escalabilidade no número de CPUs e no número de processos ativos não foram prioridades no desenvolvimento do seu Kernel.
Um usuário de PC rodando o kernel 2.4 não vai notar a menor diferença quando fizer o upgrade para o 2.6, visto que seu PC só tem 1 processador e ele só roda no máximo, digamos, 100 processos em paralelo. Além disso não se usa o linux como um Sistema Operacional para controlar um sistema de Tempo Real, como um piloto automático de um avião ou um sistema de controle de temperatura de uma usina nuclear. O Linux não foi projetado para esse tipo de coisa, mas com essas mudanças se consegue chegar mais perto do que seria um sistema mais escalável e confiável.
Segundo Theodore Tso (um dos desenvolvedores do kernel), na conversa que teve hoje com os alunos da computação no IC (Instituto de Computação - Unicamp), as futuras versões do kernel caminham em direção a se ter mais robustez para aplicações de Tempo Real, adicionando mais predictabilidade e determinismo à execução de tarefas que exigem alta prioridade.
--=[ Fontes
1) Livro: Understanding the Linux Kernel , By Daniel P. Bovet & Marco Cesati , Editora O'Reilly
2) Livro: Linux Kernel Development , By Robert Love , Editora Sams
3) Email:From: Ingo Molnar
To: linux-kernel-mailing-list
Subject: [announce] [patch] ultra-scalable O(1) SMP and UP scheduler
Date: Fri, 4 Jan 2002 03:19:10 +0100 (CET)
Este email pode ser encontrado em:
http://kerneltrap.org/node/341
4) web: http://www.hpl.hp.com/research/linux/kernel/o1.php
5) web: http://www.linuxgazette.com/node/9746
6) web: http://www.faqs.org/docs/kernel_2_4/lki-2.html
_EOF_
Loading ...
Gostei do texto porém discordo da parte que diz “Além disso não se usa o linux como um Sistema Operacional para controlar um sistema de Tempo Real, como um piloto automático de um avião ou um sistema de controle de temperatura de uma usina nuclear.” para isso já temos o Real-Time Linux [0] um patch para trazer essa característica que você diz não existir.
[0] http://rt.wiki.kernel.org/
Corrija-me se estiver errado.
Abraços.
Marcello Henrique, é assim que funciona o Linux?
@Marcello Henrique
Muito interessante sua informação, não tinha conhecimento desse patch.
[]‘s
Uma vez meu professor explicou o kernel do Linux:
“Imagine que um avião dá pau e é preciso diminuir o peso para ele não cair. Algumas pessoas devem ser jogadas, e existem duas políticas principais do Kernel nesse caso:
* Jogar a última que entrou no avião;
* Jogar uma pessoa aleatoriamente;
Por incrível que pareça é bastante razoável escolher uma pessoa aleatoriamente, o problema é que ao fazer isso pode ser que o Kernel joque o piloto.”
Mas que política ruim heim? :D
Só reduzir o espaço amostral para os passageiros e eliminar a cabine… Simples, resolveu o problema…. Por isso que existem prioridades :-D
Abração,
Roberto
Parabéns pelo post, muito interessante, e muitas informações novas , ao menos para mim
obrigado
digam-me o que é escalonamento no kernel
por favor
@monike releia o primeiro paragrafo do texto :)
[]‘s
Po show de bola, muito bom o texto. Apesar de que tambem não concordo com essa parte :
“O escalonador do Linux divide o tempo de CPU em Eras (epochs). Em cada Era, cada processo tem um time-quantum que especifica o tempo que o processo vai adquirir de CPU durante a Era atual. Quando o time-quantum de um processo acaba, o escalonador é chamado e outro processo começa a rodar.”
Pelo que eu entendo existem varias formas de se implementar o escalonador e não somente essa de chama-lo de tempos em tempos.
O Linux 2.4 e o Linux 2.6 têm Time-quantum? Para mim só tem Time-quantum o preemptivo: por exemplo, um Time-quantum de 2seg e a cada 2 seg cada processo é interrompido.
Você disse que o Linux 2.4 é não preemptivo por que não pode parar a execução como vc mesmo disse, e se tivesse Time-quantum pararia a cada tantos seg.
Tá tudo confuso!
Qual o escalonador principal do Linux 2.4? O do Linux 2.6 é R-ROBIN.
O Linux 2.4 e o Linux 2.6 têm Time-quantum?
Sim, ambos tem TQ, pois é com o uso do TQ que são é calculada a prioridade de cada processo.
Para mim só tem Time-quantum o preemptivo: por exemplo, um Time-quantum de 2seg e a cada 2 seg cada processo é interrompido.
Vou usar um exemplo para te explicar o TQ e o funcionamento das Eras, com isso vai esclarecer suas dúvidas sobre o TQ e os processos preemptivos:
Temos uma lista com 3 processos, o A,B e o C. O A tem um TQ de 3s, o B de 1.5s, o C de 2s. O algoritmo definiu a seguinte ordem de execução: B,C,A. A era foi definida com: 6.5s. Essa foi a primeira etapa, onde o escalonador definiu as ordem, agora começa a segunda etapa, que é a execução dos processos na ordem.
O processo B entra em estado de execução(running), o C em espera(waiting), e o A de stop(parado). Termina o tempo de execução do B, e o C e chamado, e B recebe o status de stop(espera), o A recebe wait. Agora o C terminou o TQ do C, ele entra em stop, o B em wait, e o A em running. Quando o A terminar seu TQ se acaba essa era e os processo retornam ao estado: B (Wait), C (wait), A (wait), agora o escalonador efetua o cálculo pelo novo TQ, agora ele definiu que o TQ dos procesos é:
A – 1.5s
B – 0.25s
C – 1s
O com o menor TQ é chamado, agora o B entra em running (em execução), quando terminar o tempo de execução dele, e chamado o próximo da lista que é o C, quando acaba o tempo do C e chamado o o A, agora o escalonador, calcula novamente a era, e define que:
A – 0.25s
B – Finalizado
C – 0.1s
Opa aconteceu algo novo, o processo B esta finalizado!Então ele recebe o status de encerrado. É o escalonador cálcula a era com base no TQ do A e C! Quando encerra essa etapa, todos os três processos foram finalizados.
Agora o ponteiro que apontava para a lista de processos na execução deixa de apontar para ela, e aponta para uma outra lista de processos, que entraram em execução agora. É um ponteiro que aponta para a lista finalizada aponta para essa lista que terminou a execução.
Entendeu o funcionamento do TQ e das eras?
Agora imagine se temos processos com TQ igual, qual vai ser executado primeiro? Será executado em fila, o primeiro que chegar e executado antes.
Agora no 2.6 o funcionamento não é baseado somente no TQ, ainda existem as eras, mas são utilizadas para definir o tempo de execução de cada processos, o que definira a ordem dos processos uma lista de prioridade.
Qual o escalonador principal do Linux 2.4? O do Linux 2.6 é R-ROBIN.
O escalonador do 2.4 é um algoritmo de complexidade(não sei se ele tem um novo específico, mas nunca vi ninguém dando um novo para ele), no 2.6 ele usa o RR para os processos com prioridade diferente e quando encontra processos com a mesma prioridade ele usa FIFO.
[]‘s
Primeiro, qual é o escalonador do Linux 2.4? É o mesmo do Linux 2.6, o RR?
Segundo, vc disse que o Linux 2.4 é não preemptivo, portanto, a execução não pode parar. E vc disse que o Linux 2.4 tem Time-quantum. Há uma contradição: o Time-quantum faz a execução parar.
No Linux 2.6, por exemplo, os processos recebem um Time-quantum de 4 seg, então, a cada 4 seg um processo para para outro executar.
Você tá entendendo?
No momento, não posso responder, mas irei responder seu questionamento.
[]‘s
Obrigado pela atenção! Na próxima quarta-feira tenho um trabalho para apresentar e não encontro nenhum material com explicação clara. Há meses estou pesquisando e quase nada. Você pode me ajudar até domingo? Tenho que estudar com os colegas da equipe. Obrigado!
Conforme o prometido, vamos lá :)
1 – Qual o escalonador do Linux 2.4?
Ele usa um algoritmo de complexidade O(n). Que é bem “idiota” se comparado com o algoritmo do 2.6.
2 – É o mesmo do Linux 2.6?
Não, é kernel 2.6 utiliza um algoritmo muito mais complexo e mais eficiente para lidar com sistemas SMP, pode ler mais sobre assunto nestes links: Inside the Linux scheduler, The Linux Scheduler
3 – vc disse que o Linux 2.4 é não preemptivo, portanto, a execução não pode parar. E vc disse que o Linux 2.4 tem Time-quantum. Há uma contradição: o Time-quantum faz a execução parar.
Você entendeu errado! O TQ(Time Quantum) é referente ao fim do processo ou seja quando o processo ou thread termina de fazer o que tem que ser feito e encerra suas operações, não é referente a troca de processos.
4 – No Linux 2.6, por exemplo, os processos recebem um Time-quantum de 4 seg, então, a cada 4 seg um processo para para outro executar.
No artigo tem o seguinte trecho que explica todo a ideia do funcionamento do TQ.
Se puder ler, recomendo o livro: Understanding the Linux Kernel escrito por Daniel P. Bovet & Marco Cesati.
Acho, assim: o escalonador do Linux 2.4 é o FIFO, os processos vão entrando e sendo executados. O problema é quando vários processos estiverem esperando para executar. Como parar o que está executando e como escolher o próximo. Um processo que terminou sua execução para sozinho? O próprio processo tem esse comando? Acho que no Linux 2.4 não há uma política de escalonamento como no Linux 2.6. Acho que os processos já possui comandos no seu código-fonte. O Linux 2.4 é não-preemptivo, automaticamente, ou seja, as execuções não podem parar automaticamente, porque não tem Time-Quantum. Acho que ele não tem Time-Quantum. Tem? Mas as execuções podem parar por meio da comunicação entre os processos. Os processos comunicam-se. Um processo chama o outro. Acho que prevalece as altas prioridades em detrimento das baixas prioridades, podendo ocorrer starvation, ou seja, o processo que tem baixa prioridade fica esperando e nunca será executado, então, “morre de fome”. Starvation quer dizer morrer de fome. No Linux 2.4 pode ocorrer starvation? Tudo, acho!
•Qual o escalonador do Linux 2.4?
•O Linux 2.4 é não-preemptivo?
•O Linux 2.4 tem Time-Quantum?
•Acho que não-preemptivo não tem Time-Quantum.
A grosso modo o escalonador do 2.4 tem o seguinte algoritmo:
Para (cada processo no sistema) { Ache o valor de “merecimento” (prioridade dinâmica) do processo; Se (esse é o processo com maior “merecimento” (ou seja, maior prioridade)) { Lembre-se desse processo } } Rode o processo com maior “merecimento”;Agora no 2.6 o algoritmo e mais inteligente, a grosso modo ele faz o seguinte processo:
1 – Busca a fila com maior prioridade;
2 – Pegue o primeiro processo nessa fila;
3 – Rode esse processo;
Lembrando que cada fila ainda tem sua era, e cada processo ainda tem o TQ! Pois o TQ informara quando tempo o processos ficará sendo executado.
Qual o escalonador do Linux 2.4?
Respondi em outro comentário.
O Linux 2.4 é não-preemptivo?
Ele é sim, o kernel e preemptivo desde o 2.2
O Linux 2.4 tem Time-Quantum?
Sim, foi justamente nele que surgiu o TQ.
Acho que não-preemptivo não tem Time-Quantum.
Não confunda o funcionamento do TQ, ele não serve só para dizer que o processo ficará x segundos no processador, é usado para calcular a era! Que é o tempo de vida da fila. No kernel 2.6 a era é uma variável importante no cálculo da prioridade, da fila.
[]‘s
Quer dizer que no Linux 2.4 cada processo individualmente de acordo com sua característica recebe um Time-Quantum específico. Pode ter um com maior Time-Quantum e outro com menor Time-Quantum.
Time-Quantum é o tempo total do processo?
Eu pensava que Time-Quantum era o tempo mínimo para troca de processo.
No Linux 2.4 como é que um processo é interrompido para outro processo executar? Eu penso que no Linux 2.4 o processo executa até o final e depois é que dá lugar para outro processo.
No Linux 2.6 é um único Time-Quantum para todos os processos ou cada processo tem seu Time-Quantum? Peguei um exemplo que era um único Time-Quantum para todos e a prioridade vai baixando para que todos os processos possam executar e não ocorra starvation, ou seja, um processo não execute.
Eu queria que você dissesse assim: o algoritmo escalonador do Linux 2.4 é o Round-Robin ou FIFO ou … ou todos juntos ou nenhum.
No Linux 2.6 o principal algoritmo escalonador é o Round-Robin, mas pode ser usado o FIFO e outros menores.
Vou apresentar esse trabalho e quero ter certeza da verdade.
Quer dizer que no Linux 2.4 cada processo individualmente de acordo com sua característica recebe um Time-Quantum específico. Pode ter um com maior Time-Quantum e outro com menor Time-Quantum. Time-Quantum é o tempo total do processo?
Cada processo recebe seu TQ, é sim podem ter TQ diferentes ou iguais, só depende das características do processo. O processo “não tem” um tempo total de execução, o TQ dele e sempre recalculado a cada era, até chegue um momento que o processo termine sua execução.
Eu pensava que Time-Quantum era o tempo mínimo para troca de processo.
Exato, e o tempo para troca de processos mesmo :)
No Linux 2.4 como é que um processo é interrompido para outro processo executar? Eu penso que no Linux 2.4 o processo executa até o final e depois é que dá lugar para outro processo.
Olha nenhum processo e executado até final, com exceção dos processos de real-time, or exemplo: os módulos do kernel eles rodam em tempo real. Mas tem que tomar cuidado com isso, pois cada processo tem suas caracteristicas, as vezes até processos de real-time pode entrar em espera, por exemplo um processo precisa da informação que e processada por outro processo para continuar sua execução, então nesse caso ele vai aguardar até ter a informação disponível.
No Linux 2.6 é um único Time-Quantum para todos os processos ou cada processo tem seu Time-Quantum? Peguei um exemplo que era um único Time-Quantum para todos e a prioridade vai baixando para que todos os processos possam executar e não ocorra starvation, ou seja, um processo não execute.
No kernel 2.6, existe o TQ e a era ainda, a era é o somatório dos TQ, cada processo, job, thread possui um TQ, a era uma variável muito importante no cálculo da prioridade da fila e dos processos a serem executados.
Eu queria que você dissesse assim: o algoritmo escalonador do Linux 2.4 é o Round-Robin ou FIFO ou … ou todos juntos ou nenhum.
Ele usa um algoritmo de complexidade. o Kernel 2.6 usa o RR + FIFO. Aqui você encontrara mais informações sobre o algoritmo do 2.4
No Linux 2.6 o principal algoritmo escalonador é o Round-Robin, mas pode ser usado o FIFO e outros menores.
Não, cuidado com essa afirmação, sim o kernel 2.6 usa o Round-Robin, mas quando se depara com processos com a mesma prioridade ele utiliza FIFO.
Boa sorte com a apresentação.
[]‘s
Amigo, VonNaturAustreVe, agradeço-lhe por toda a sua ajuda. Desculpe-me a canseira. Obrigado!
Estou ae para isso xD
Boa sorte com a apresentação, e muito sucesso :)
[]‘s
Olá, VonNaturAustreVe, tirei 10 na apresenta~
ção do trabalho. Obrigado pela ajuda!
Você pode me ajudar nessas questões finais?
1-Como o RR gerencia dois CPU-bound e o efeito da variação de fatia de tempo? Nesse caso,o CPU-bound pode ser interrompido para que o outro CPU-bound execute ou cada um executa até terminar?
2-No RR quais devem ser os critérios para determinar as prioridades dos processos?
Qual os benefícios no escalonamento RR quando todos os processos são criados com a mesma prioridade?
3-Duas soluções para resolver o starvation no RR?
4- RR dinâmico. Qual o critério utilizado pelo SO para determinar diferentes valores de incremento à prioridade-base de um processo quando há uma mudança do estado de espera para pronto?
Olá, VonNaturAustreVe. Tirei 10 no trabalho. Obrigado!
Vc pode me ajudar numas questões finais?
1-Como RR gerencia 2 processos CPU-bound? O CPU-bound ganha QUANTUM? O CPU-bound pode ser interrompido? A variação de fatia de tempo interfere desigualmente?
2-Quais os critérios para determinar as prioridades dos processos no RR?
No RR qual o benefício quando todos os processos são criados com a mesma prioridade?
3-2 ações para resolver o starvation no RR?
4-Qual o critério utilizado pelo SO para determinar diferentes valores de incremento à prioridade-base de um processo quando há uma mudança do estado de espera para pronto?
Estou sem tempo no momento para responder, assim que surgiu uma hora livre lhe envio as respostas por email :)
[]‘s