[Ostep] 04 Estratégia de programação de processo de CPU virtualizada

Estratégia de agendamento de processos

Chamamos os processos em execução no sistema de carga de trabalho. Quanto mais gerais nossas suposições sobre a carga de trabalho , mais otimizado será o desempenho da estratégia de agendamento projetada com base nessa suposição.

A discussão a seguir assume que a carga de trabalho ocupa apenas a CPU e não emite nenhuma operação de E / S.

Índice de programação

Indicadores de programação são usados ​​para medir os prós e contras de diferentes estratégias de programação

• Tempo de resposta

  É o tempo que leva para uma tarefa passar para o sistema operacional até o final de sua operação.

  Tempo de retorno do trabalho = tempo de conclusão do trabalho - tempo de chegada do trabalho

  Este indicador analisa principalmente o tempo médio de retorno : o valor médio do tempo de retorno de várias tarefas durante um período de tempo.

  Tempo médio de rotação = Soma do tempo de rotação / número de trabalho

• Tempo de resposta (tempo de resposta)

  É o tempo que leva para uma tarefa ser entregue ao sistema operacional para começar a ser executada (o sistema operacional responde à tarefa).

  Tempo de resposta de trabalho = tempo de trabalho da primeira execução - tempo de chegada do trabalho

  Este indicador analisa principalmente o tempo médio de resposta : a média do tempo de resposta de várias tarefas durante um período de tempo.

  Tempo médio de resposta = soma do tempo de resposta / número de empregos

Otimize o tempo médio de resposta

Primeiro a entrar, primeiro a sair (FIFO, FCFS)

Primeiro a entrar, primeiro a sair ( primeiro a entrar, primeiro a sair) ou por ordem de chegada

A ideia é muito simples, ou seja, quem chegar primeiro será executado primeiro (até o fim do trabalho).

Sob essa estratégia, após a chegada de cada tarefa, ele precisa esperar que as tarefas anteriores sejam concluídas antes de obter uma resposta, e seu tempo de retorno depende do tempo de execução do trabalho que chegou primeiro.

Supondo que os três processos de abc cheguem ao mesmo tempo um após o outro, e o tempo de execução seja conhecido, eles são abc respectivamente.

Tempo médio de resposta = [a + (a + b) + (a + b + c)] / 3 = (3a + 2b + c) / 3

Tempo médio de resposta = [0 + a + (a + b)] / 3 = (2a + b) / 3

Independentemente do indicador, essa estratégia não está bem otimizada para o efeito comboio (problema de fila de espera).

Tarefa mais curta primeiro (SJF, SPN)

Trabalho mais curto primeiro ou processo mais curto a seguir

Esta estratégia é uma estratégia primeiro a entrar, primeiro a sair, que leva em conta o efeito de escolta. Para várias tarefas que chegam ao mesmo tempo, a tarefa com o menor tempo tem prioridade (ganancioso).

Supondo que os três processos de abc cheguem ao mesmo tempo um após o outro, e o tempo de execução seja conhecido, eles são abc respectivamente.

Tempo médio de resposta = [a + (a + b) + (a + b + c)] / 3 = (3a + 2b + c) / 3

Tempo médio de resposta = [0 + a + (a + b)] / 3 = (2a + b) / 3

Esta estratégia considera o efeito escolta, mas só é otimizada para cada grupo de tarefas que chegam ao mesmo tempo.

Se a tarefa a chegar primeiro, bc chegará após o término da execução da estratégia, e não há diferença entre a estratégia primeiro a entrar, primeiro a sair neste momento:

Esse problema pode ser resolvido se as tarefas mais demoradas que chegam mais tarde puderem prejudicar diretamente a CPU.

Tarefa preemptiva mais curta primeiro (PSJF, STCF)

Trabalho mais curto preventivo primeiro ou menor tempo para conclusão primeiro

O SJF preventivo considera o efeito de escolta imediatamente.

Suponha que o processo a chegue primeiro e o processo bc chegue ao mesmo tempo um após o outro e o tempo de execução seja conhecido, respectivamente abc.

Tempo médio de resposta = [a + (a + b) + (a + b + c)] / 3 = (3a + 2b + c) / 3

Tempo médio de resposta = [0 + a + (a + b)] / 3 = (2a + b) / 3

Para o tempo de retorno, se o tempo de retorno de todos os trabalhos for conhecido, este é o algoritmo de programação ideal.

No entanto, ainda temos um indicador de agendamento para discutir, o tempo médio de resposta.

O tempo médio de retorno e o tempo médio de resposta são como as patas de peixe e urso. Os dois são incompatíveis. Vamos dar uma olhada na estratégia Round-Robin que otimiza o tempo médio de resposta.

Otimize o tempo médio de resposta

Rotação (RR)

Pode ser denominado round robin ou polling .

A rotação é uma estratégia justa. Ela executa um trabalho em uma fração de tempo (ou quantum de programação) e alterna para a próxima tarefa na fila na próxima fração de tempo e assim por diante. Até que todas as tarefas tenham terminado.

Suponha que uma fração de tempo seja t, abc chega uma após a outra ao mesmo tempo e o tempo de execução é conhecido, respectivamente, abc.

[Falha na transferência da imagem do link externo. O site de origem pode ter um mecanismo de link anti-leech. É recomendado salvar a imagem e carregá-la diretamente (img-4OUVBKmF-1610107587742) (C: \ Users \ 10199 \ AppData \ Roaming \ Typora \ typora-user-images \ image-20210107155028268.png)]

Tempo médio de resposta = [(a + b + c) + t + (a + b + c) + (a + b + c) -t] / 3 = a + b + c

Tempo médio de resposta = [0 + t + 2t] / 3 = t

Sob essa estratégia justa, qualquer processo tem uma chance de obter uma resposta rápida. O tempo médio de resposta é bastante ideal, mas o tempo médio de retorno é a soma do tempo de execução de todas as tarefas. O desempenho é muito ruim, ainda pior do que FIFO . Na verdade, qualquer estratégia justa levará a um desempenho ruim no tempo de resposta e você não pode ter os dois.

Além disso, a operação de troca de contexto também requer uma certa quantidade de overhead. A troca muito frequente trará perda de desempenho desnecessária. Estenda razoavelmente a fatia de tempo para amortizar o custo de troca de contexto e garantir que o sistema responda a tempo.

No entanto, é definitivamente uma escolha sábia mudar constantemente de contexto. Encurtar o tempo de resposta permite ao operador compreender com mais precisão o status da máquina e melhorar a taxa de utilização do sistema (para fazer as pessoas se sentirem felizes).

Outra vantagem da ideia do RR é melhorar a utilização da CPU quando combinada com E / S.

Deixe outro processo antecipar a CPU enquanto espera por um dispositivo de E / S.

Fila de feedback multinível (MLFQ)

As estratégias de agendamento que acabamos de discutir baseiam-se em uma premissa principal ideal - o sistema operacional entende com precisão a duração de cada trabalho. Na verdade, o sistema operacional sabe muito pouco sobre isso.

Então, o que discutiremos a seguir é:

"Como projetar um planejador com capacidade preditiva para aproximar o excelente desempenho de SJF e PSJF no tempo médio de resposta?"

Também precisamos combinar o RR para obter um bom tempo médio de resposta.

Breve introdução

Fila de feedback multinível

Essa estratégia tem uma série de filas, cada fila pode ter vários trabalhos e diferentes filas têm diferentes prioridades.

Em seguida, o planejador sempre executa as tarefas na fila de alta prioridade por sua vez.

Como queremos obter o efeito de PSJF, as tarefas curtas são executadas primeiro em PSJF. Correspondentemente, no MLFQ, as tarefas de alta prioridade serão executadas primeiro, o que significa que as tarefas de alta prioridade são consideradas tarefas curtas pelo sistema operacional, ou seja , quanto maior a prioridade de um processo, melhor seu desempenho histórico. Atos próximos de trabalhos curtos .

Sendo esse o caso, como podemos prever o comportamento de um trabalho e determinar sua prioridade?

A ideia básica é que, quando um trabalho entra no sistema operacional, presumimos que é um trabalho curto ou de E / S intensivo (interativo) e atribuímos a ele a maior prioridade. Se for realmente um trabalho curto, ele será executado em breve; caso contrário, pode ser um trabalho longo ou um trabalho intensivo da CPU e será gradualmente movido para uma fila de prioridade mais baixa .

regra

No MLFQ a prioridade do processo não é estática, o escalonador ajusta constantemente a prioridade de cada trabalho em tempo real de acordo com várias regras.

Em primeiro lugar, presumimos que um trabalho é curto e interativo.

Regra 1: quando o trabalho entra no sistema operacional, ele é colocado na fila de prioridade mais alta.

Se o tempo de execução desse trabalho for muito longo, provavelmente será um trabalho que consome muita CPU e demorará muito, portanto, há a regra dois.

Regra 2: Uma vez que o tempo do trabalho se esgota em uma determinada prioridade, a prioridade é reduzida.

Se tarefas curtas e interativas continuarem a fluir e os recursos da CPU forem muito usados, também esperamos que tarefas longas possam ser tratadas de maneira justa.

Ou, se um trabalho longo se tornar um trabalho interativo durante um período de tempo, devemos tratá-lo de maneira mais justa. Portanto, precisamos aumentar a prioridade no tempo, para que haja a regra três.

Regra 3: Após um período de tempo acordado, todo o trabalho será movido para a fila de prioridade mais alta.

Obviamente, adicionar o período de tempo S leva a questões óbvias: como o valor de S deve ser definido? O respeitado pesquisador de sistemas John Ousterhout uma vez se referiu a esse valor como a "constante voo-doo" porque parecia exigir um pouco de magia negra para defini-lo corretamente. Se S for definido muito alto, os trabalhos longos ficarão famintos; se for definido muito baixo, os trabalhos interativos não terão uma proporção de tempo de CPU adequada.

Detalhes de implementação

Muitos detalhes do MLFQ não são fornecidos, por exemplo:

• Número de filas
• Comprimento do intervalo de tempo de cada fila
• O intervalo de prioridade para todos os grupos

Não existe uma solução ideal para esses detalhes.Há muitas implementações específicas baseadas nas ideias do MLFQ, cada uma com suas próprias características.

Detalhes de implementação na atribuição

Devo antecipar diretamente a CPU quando o trabalho de E / S terminar?

A antecipação quase não tem efeito sobre o período médio de giro (mas pode alterar o período de giro) e tem um certo impacto no período médio de resposta.

Porque, quando o trabalho interativo continua ocupando a CPU, o trabalho que chega depois será difícil de executar.

Quota proporcional

Breve introdução

Participação proporcional ou participação justa

O objetivo não é otimizar o tempo de retorno e o tempo de resposta, mas garantir que cada trabalho receba uma determinada porcentagem de tempo de CPU.

Agendamento de loteria

A programação de loteria é uma implementação da estratégia de compartilhamento proporcional. A ideia básica é decidir para qual processo mudar em seguida por meio de uma loteria.

Cada processo contém um determinado número de bilhetes ( traduzido como uma loteria no livro, acho que não é preciso), e a participação do processo é determinada pela proporção dos bilhetes detidos por cada processo em todos os bilhetes. No final de cada fração de tempo, o planejador usa números aleatórios para determinar qual processo será executado em seguida.

Os recursos da CPU ocupados por cada processo convergem para a parcela detida por ele com probabilidade.

Mecanismo de loteria

• Moeda da loteria (moeda do bilhete)

  O usuário detém uma certa quantidade de moeda, e a moeda pode ser alocada para os processos sob o usuário. O sistema operacional irá converter a moeda mantida pelo processo em cupons de acordo com a proporção da moeda de cada usuário.

• Transferência de loteria (transferência de bilhete)

  Um processo pode transferir temporariamente seus próprios cupons para outro processo para aumentar sua participação.

• Inflação da loteria (inflação do bilhete)

  Em um ambiente de confiança mútua entre processos, um processo pode aumentar ou diminuir temporariamente o número de cupons que possui.

Como determinar a participação

O objetivo desta estratégia não é resolver o problema da distribuição, a distribuição das ações pode ser estipulada artificialmente.

Por exemplo, em supercomputação, é razoável alocar um recurso fixo de CPU para um determinado usuário.

alcançar

loteria:

// counter: used to track if we’ve found the winner yet
int counter = 0;

// winner: use some call to a random number generator to
//         get a value, between 0 and the total # of tickets
int winner = getrandom(0, totaltickets);

// current: use this to walk through the list of jobs
node_t *current = head;
while (current) {
    
    
    counter = counter + current->tickets;
    if (counter > winner)
        break; // found the winner
    current = current->next;
}
// ’current’ is the winner: schedule it...

Além disso, quando o tempo de execução não é muito longo, a aleatoriedade da loteria não parece necessariamente justa.

Portanto, existe um algoritmo de escalonamento que garante um escalonamento justo por etapas .

Programação Stride

Idéia básica: Calcule o comprimento da etapa de acordo com os cupons de cada processo, por exemplo, os comprimentos das etapas dos dois processos com o número de cupons 1 e 2 são 2 e 1, respectivamente. Cada vez que um processo obtém recursos da CPU para uma fração de tempo, seu valor de curso acumula uma etapa. Contanto que seja garantido que o valor do curso de cada processo programado não seja maior do que o de outros processos, esse método de programação é justo.

O livro diz que se um processo for atingido pela metade, o valor do curso do processo não será fácil de determinar, portanto, esse método não é fácil de implementar.

Acho que podemos conseguir isso:

Porque o valor do curso de todos os processos é sempre o mesmo periodicamente. Quando eles são consistentes, todos os valores de curso são apagados e, em seguida, o processo que chegou na metade do caminho é adicionado e o valor de curso é definido como zero e, em seguida, a parcela proporcional e o valor do passo são recalculados.

O problema com meu método é que a operação de limpar todos os valores de curso tem uma sobrecarga considerável.

Em outras palavras, quando for consistente, adicione o processo que chegou no meio do caminho e defina o valor do curso para ser igual ao valor do curso atual e, em seguida, limpe-o quando o espaço de memória usado para salvar o valor do curso estiver prestes a transbordar.