Я знаю, что существуют приоритеты процессов, как и в других операционных системах, от -20 (больший приоритет) до 19 (меньший приоритет), но Linux, похоже, их игнорирует.
Прямо сейчас я собирал ядро в фоновом режиме (хотя makeу процессов приоритет 0), и поскольку это заняло довольно много времени, я решил что-нибудь посмотреть. Поэтому я открыл довольно требовательное видео H264 (~30% процессорного времени Core2 2.6GHz) в VLC, только чтобы обнаружить разрывы, потерю кадров, визуальные артефакты (я полагаю, из-за предыдущего), хотя звук, казалось, был в порядке.
Поэтому я решил изменить приоритет VLC renice, используя конкретно, видя, что PulseAudio имеет, -11я решил поставить его на один уровень, что я и сделал sudo renice -11 -p VLC_PROC_#.
То же самое происходило и дальше, поэтому я установил значение -20, но визуальные артефакты все равно продолжали появляться.
Вот мне интересно, почему Linux на самом деле не приоритизировал процесс -20 над некоторыми процессами 0 и не дал ему все, что нужно? Есть ли способ действительно приоритизировать процессы в Linux?
Если это имеет значение, я использую 64-битную версию Arch, XFCE в качестве среды рабочего стола.
РЕДАКТИРОВАТЬ:Была выполнена компиляция ядра, в /tmpкоторой у меня есть tmpfsего исходники, и все они уже были в оперативной памяти. Использование оперативной памяти даже не достигло 60%, и не было никаких операций подкачки.
Описанный выше сценарий — это всего лишь пример.прецедент, меня больше интересует, почему Linux добился таких результатов, и есть ли способ получить реальные приоритеты.
решение1
reniceвлияет на приоритет процесса. Но, как вы уже поняли, то, что у процесса более высокий приоритет, не означает, что у него будут все необходимые ресурсы. Более высокий приоритет просто дает процессу больше шансов захватить ресурсы.
reniceвлияет только на время ЦП. Поэтому он влияет только в том случае, если два или более процессов конкурируют за время ЦП. Если ограничивающим фактором является не время ЦП, а пропускная способность ввода-вывода, значение nice не оказывает никакого влияния. Возможно, в вашем случае компиляция использует большую пропускную способность диска, и vlc не может достаточно быстро считывать данные с диска. Попробуйтеioniceвместо или в дополнение к nice.
Если вы делаете это часто, вы получите лучшие результаты, если видео и компиляция находятся на разных дисках. Также вы можете получить лучшие результаты, если вы предварительно загрузите видео в кэш диска ( cat /path/to/video.file >/dev/nullили tail -c +456m | head -c 123m /path/to/video.file >/dev/nullдля чтения 123 МБ, начиная со смещения 456 МБ) — но если у вас нет большого объема оперативной памяти, компиляция, скорее всего, потребует обратно место в кэше. Если вы хотите быть уверены, что видео находится в памяти, создайте ramdisk и скопируйте видео на него.
решение2
Приоритет процесса — это не единственное, что имеет значение, когда вы пытаетесь настроитьПользовательский опыт. Компиляция ядра — это довольно интенсивный процесс ввода-вывода — много чтения/записи из/в небольшие файлы, что может значительно растянуть файловую систему (есть причина, по которой это иногдаиспользуется как самостоятельный эталон), особенно на многопроцессорной машине. Если у вас достаточно оперативной памяти, я предлагаю вам попробовать скомпилировать ядро в tmpfs - по крайней мере частично: либо поместить туда исходное дерево (что фактически будет выполнять функцию предварительной загрузки его в кэш), либо отправить туда вывод с помощью
make O=/dev/shm ...
или в любом другом месте, где вы решите смонтировать свой tmpfsэкземпляр, достаточно большой для хранения объектных файлов ядра (которые могут легко достигать гигабайтного размера).
Кроме того, вы также можете проверить, есть ли у VLC функция кэширования (я предполагаю, что есть, например, для MPlayer есть такая -cacheопция), с помощью которой вы можете запросить кэширование данных внутри. Тогда ему не нужно будет получать данные по мере необходимости, а когда они станут доступны.
Другое дело, что отображение осуществляется через X-сервер - его приоритет также придется повысить (см. комментарий Wumpus Q. Wumbley под вопросом).
Еще два варианта — использование cgroups и/или RT scheduler (первый вариант см., например,управление приоритетом приложений с помощью cgroups, для последнего см., например,Инструкции Gentoo).
Последнее, что вам может понадобиться, это немного оптимизировать вашу систему, отключив ненужные службы. Лично я бы считал, что начать следует с PulseAudio.
Однако то, что вы описываете, больше похоже на высокоприоритетный ввод-вывод - я предполагаю, что у вас был какой-то интенсивный свопинг - вы уверены, что ваш tmpfs не был принудительно выгружен? В этом случае, боюсь, по крайней мере iorenice не поможет.
решение3
Как уже говорили другие, затронуть можно многие части системы, включая пропускную способность памяти, и эти другие части системы также будут иметь собственное планирование и приоритеты.
Вы всегда можете использовать его chrt -i 0, чтобы дать компиляции настоящий приоритет простоя.
http://linux.die.net/man/1/chrt
Или замедлите компиляцию с помощью cgroups. http://kennystechtalk.blogspot.co.uk/2015/04/throttling-cpu-usage-with-linux-cgroups.html
Или бросьте на него все силы:
eatmydata cgexec -g cpu:throttled chrt -i 0 ionice -c3 nice -n19 /path/to/compile-script >/dev/null
Примечание: использование nice -n19не должно иметь никакого значения chrt -i 0, но и вреда это ничему не принесет.
Мой древний P4 может делать то же самое, не вызывая проблем с VLC.