Existe uma maneira de realmente priorizar os processos ou fazer o Linux respeitar suas prioridades?

Existe uma maneira de realmente priorizar os processos ou fazer o Linux respeitar suas prioridades?

Eu sei que existem prioridades de processo como em outros sistemas operacionais, indo de -20 (mais prio) a 19 (menos prio), mas o Linux parece ignorá-las.

No momento eu estava construindo o kernel em segundo plano (embora makeos processos tenham prioridade 0) e como demorou um pouco decidi assistir algo. Então abri um vídeo H264 bastante exigente (~30% do tempo de CPU de um Core2 2,6 GHz) no VLC apenas para descobrir que havia tearing, perda de quadros, artefatos visuais (resultantes do anterior, presumo), embora o áudio parecesse estar multar.

Então decidi mudar a prioridade do uso do VLC renice, vendo concretamente que o PulseAudio tinha, -11decidi colocá-lo no mesmo nível, então o fiz sudo renice -11 -p VLC_PROC_#.

A mesma coisa continuou acontecendo, então configurei para -20, mas ainda continuei vendo artefatos visuais.

Então eu me pergunto: por que o Linux não priorizou um processo -20 em vez de alguns processos 0 e deu a ele tudo o que precisava? Existe alguma maneira de realmente priorizar processos no Linux?

Caso seja importante, estou executando um Arch de 64 bits aqui, XFCE como ambiente de desktop.

EDITAR:Foi realizada a compilação do kernel no /tmpqual tenho como tmpfstal seus fontes e todos já estavam na RAM. O uso de RAM nem chegou a 60% e não houve operações de paginação.

O cenário detalhado acima é apenas umcaso de teste, estou mais interessado em saber por que o Linux teve esse desempenho e se há alguma maneira de obter prioridades reais.

Responder1

reniceafeta a prioridade de um processo. Mas, como você percebeu, só porque um processo tem prioridade mais alta não significa que ele terá todos os recursos necessários. Uma prioridade mais alta apenas dá ao processo uma chance maior de obter recursos.

reniceafeta apenas o tempo da CPU. Portanto, isso só terá efeito se dois ou mais processos estiverem competindo pelo tempo de CPU. Se o fator limitante não for o tempo de CPU, mas a largura de banda de E/S, o valor agradável não terá impacto. Talvez no seu caso a compilação esteja usando muita largura de banda do disco e o vlc não consiga ler os dados do disco com rapidez suficiente. Tentarioniceem vez disso ou além de nice.

Se você fizer isso com frequência, obterá melhores resultados se o vídeo e a compilação estiverem em discos separados. Além disso, você pode obter melhores resultados se pré-carregar o vídeo no cache do disco ( cat /path/to/video.file >/dev/nullou tail -c +456m | head -c 123m /path/to/video.file >/dev/nulller 123 MB começando no deslocamento de 456 MB) - mas, a menos que você tenha muita RAM, a compilação provavelmente reivindicará o espaço do cache de volta. Se você quiser ter o vídeo na memória, crie um ramdisk e copie o vídeo para ele.

Responder2

A prioridade do processo não é a única coisa que entra em jogo quando você está tentando ajustarexperiência de usuário. Compilar o kernel é uma tarefa bastante pesada de E/S - muita leitura/gravação de/para arquivos pequenos que podem esticar um pouco o sistema de arquivos (há uma razão pela qual às vezes éusado como referência por direito próprio), especialmente em uma máquina multiprocessada. Se você tiver RAM suficiente, sugiro que você tente compilar o kernel em tmpfs - pelo menos parcialmente: coloque a árvore de origem lá (que atuará efetivamente como uma pré-busca no cache) ou envie a saída para lá usando

make O=/dev/shm ...

ou onde quer que você decida montar sua tmpfsinstância grande o suficiente para conter os arquivos de objeto do kernel - que podem facilmente estar na faixa de gigabytes).

Além disso, você também pode verificar se o VLC tem um recurso de cache (meu palpite é que tem, por exemplo, o MPlayer tem a -cacheopção) com o qual você pode solicitar o cache dos dados internamente. Então ele não precisa obter os dados conforme necessário, mas quando eles estiverem disponíveis.

Outra coisa é que a exibição é feita através do servidor X - sua prioridade também teria que ser aumentada (veja o comentário de Wumpus Q. Wumbley na pergunta).

Mais duas opções são usar cgroups e/ou agendador RT (para a primeira veja, por exemplocontrolando a prioridade de aplicativos usando cgroups, para este último ver, por exemplo, oInstruções Gentoo).

A última coisa é que você pode querer otimizar um pouco o seu sistema, desativando serviços desnecessários. Pessoalmente, eu consideraria o PulseAudio como o ponto de partida.

No entanto, o que você descreve parece mais com alguma E/S de alta prioridade acontecendo - meu palpite é que você passou por algumas trocas pesadas - tem certeza de que seus tmpfs não foram forçados a serem trocados? Nesse caso, temo que pelo menos Iorenice não vá ajudar muito.

Responder3

Como já foi dito, há muitas partes de um sistema que podem ser afetadas, incluindo a largura de banda da memória, e essas outras partes do sistema também terão seus próprios agendamentos e prioridades.

Você sempre pode usar chrt -i 0para dar à compilação a prioridade ociosa verdadeira. http://linux.die.net/man/1/chrt

Ou limite a compilação usando cgroups. http://kennystechtalk.blogspot.co.uk/2015/04/throttling-cpu-usage-with-linux-cgroups.html

Ou jogue tudo nisso:

eatmydata cgexec -g cpu:throttled chrt -i 0 ionice -c3 nice -n19 /path/to/compile-script >/dev/null

Nota: nice -n19não deve fazer diferença se chrt -i 0for usado, mas também não fará mal nenhum.

Meu antigo P4 pode fazer a mesma coisa sem que o VLC fique chateado.

informação relacionada