Por que a inicialização de um novo aplicativo causa gagueira no sistema

Question

Todos os sistemas operacionais modernos são compatíveis com multitarefa. Assim, cada aplicativo em execução receberia uma certa fatia de tempo da CPU para sua operação (dependendo da demanda).

As perguntas são, se o intervalo de tempo é sempre calculado (o que é, eu acho), então por que um aplicativo pode estagnar todo o sistema operacional (ou a máquina).

Diga, estou tocando uma trilha sonora usando o player VLC. Então eu corro o NetBeans (um IDE). Então o som do VLC player começa a gaguejar (e continua até que o NetBeans fique completamente responsivo). Mas o player VLC sempre deve ter seu intervalo de tempo intacto, certo? ou está apenas realocando novo intervalo de tempo para o novo software que faz a queda da fatia necessária para um aplicativo já em execução?

    

Answer 1

Why the startup of a new application causes system stuttering

Then sound from VLC player starts stuttering

Você apenas forneceu um exemplo de "gagueira", e não é o sistema que gagueja, mas um programa aplicativo sensível à latência de I / O. Em poucas palavras, seu sistema atingiu um limite para sua largura de banda de E / S.

So, each running app would get a certain amount of time slice from cpu for their operation(depending on their demand)

Talvez, ou talvez não. O agendador do sistema operacional pode usar timeslices para alocar tempo de CPU para cada processo, ou um esquema prioritário de preferência pode ser utilizado. Ou, se o agendamento cooperativo for usado, um processo pode permitir que a CPU ative até que ela abandone o controle. Um "sistema operacional moderno" oferecerá aos programadores de sistema e aplicativos muitas opções para adaptar o agendamento.

Mas vamos supor que um agendamento de timeslicing round-robin seja usado em seu exemplo. O player VLC deve ser categorizado como um programa intensivo de E / S , ao contrário de um intensivo de CPU . Essencialmente, o player VLC é repetidamente

• lendo dados (de um arquivo de disco)
• escrevendo os dados (no dispositivo de áudio)

O player VLC não utiliza seu intervalo de tempo para cálculos intensivos, mas principalmente para executar uma operação de entrada ou saída e, em seguida, é suspenso até que a operação de E / S seja concluída. Dependendo do agendador do sistema operacional, a porção não utilizada da timeslice pode ser creditada de volta ao processo por um período de tempo extra longo no próximo go-around, ou o processo perde, ou o processo chega ao início da fila pronta como assim que a E / S for concluída. O que acontece exatamente dependerá de como o planejador do sistema operacional é implementado. Por exemplo, o kernel do Linux pode ser construído para usar um dos vários agendadores, cada um com características diferentes de "justiça" para diferentes tipos de processos.

Então, quando você inicia o NetBeans, inicia uma enxurrada de leituras de disco para localizar e carregar o código do aplicativo e as bibliotecas compartilhadas. Muito provavelmente, essa atividade adicional do disco é misturada com as solicitações do player VLC e faz com que cada leitura do VLC demore mais do que a latência aceitável, portanto, o dispositivo de áudio fica sem dados e, portanto, a "gagueira" audível.

Infelizmente, os agendadores tendem a se concentrar na alocação de recursos da CPU e têm dificuldade (ou evitar lidar) com problemas de E / S imprevisíveis. Você pode tentar uma unidade de disco mais rápida e / ou localizar o arquivo de áudio em uma unidade diferente da unidade de programas do OS +.

Seu problema está relacionado aos sistemas realtime e near-realtime , que lidam com respostas confiáveis e rápidas / previsíveis aos eventos. A reprodução de vídeo e áudio não tolera a latência de E / S variável e possui algumas características dos sistemas near-realtime . Os jogadores devem incorporar técnicas usadas em sistemas quase em tempo real se o sistema operacional tiver recursos como prioridades de processo.

A rede tem sido responsiva ao lidar com tráfego de baixa latência versus tráfego comum, já que tinha que resolver esse problema para VoIP. Algo semelhante é necessário para sistemas de armazenamento em massa.

    

Answer 2

Como um sistema operacional pode fornecer a mesma quantidade de CPU a um aplicativo que é o único que está tentando executar quando ele dá a esse aplicativo quando outros 18 estão tentando ser executados? A única maneira é dar à aplicação apenas uma pequena fração dos recursos disponíveis, mesmo quando for a única. Isso obviamente seria um desastre.

Quando o sistema precisa executar dois aplicativos, para uma primeira aproximação, para cada recurso que ambos desejam consumir, metade dos recursos disponíveis estão disponíveis para cada aplicativo. Se ambos querem muita memória, cada um deles terá metade. Se ambos quiserem muitos I / Os de disco, cada um deles receberá metade. Se ambos quiserem muito tempo de CPU, cada um receberá metade. Mais ou menos.

Se são três aplicativos, eles não podem ter mais de 1/3.

Como os agendadores lidam com o tempo de CPU varia. Mas, como um exemplo simples para um sistema de núcleo único, funciona assim: se houver apenas uma tarefa pronta para execução, essa tarefa iniciará uma nova fatia de horário assim que terminar uma fatia de tempo. Se houver duas tarefas prontas para execução, elas alternam timeslices.

Na prática, é muito mais complicado. Por exemplo, se uma tarefa não usa o seu horário completo, ela geralmente recebe um aumento de prioridade. O mesmo pode ser aplicado se uma tarefa for interrompida pela E / S do sistema. Na prática, isso tende a dar mais resposta ao sistema. (Imagine que você está olhando para uma página da Web por um longo tempo e então clica em um botão. Como seu navegador estava sendo agradável e produzindo a CPU enquanto você lê, quando de repente precisa da CPU, ela é recompensada por ser legal e melhorar a interatividade.)