Как процессы Linux производят графический вывод 60 раз в секунду, если временной интервал по умолчанию равен 100 мс? - PullRequest
0 голосов
/ 26 февраля 2020

Есть кое-что, что я принципиально не понимаю о том, как многозадачность работает в Linux (и, вероятно, также в целом). Если я правильно понимаю, каждый раз, когда процесс хочет изменить свой вывод на экран, он должен делать некоторые вычисления и отправлять данные. Но если я правильно понимаю, процессы могут перегружать процессор до 100 мс, прежде чем их прервут по умолчанию настройки большинства Linux дистрибутивов . Казалось бы, это исключает возможность достаточно частой разблокировки процессов, чтобы можно было обновить sh экран при 60 Гц. В свете этого, я полагаю, что у меня есть целый ряд фундаментальных недоразумений о том, как Linux управляет дефицитным временем ЦП и / или о том, как процессы отправляют данные на устройства ввода-вывода.

Вопрос. Что здесь происходит?

Ответы [ 2 ]

1 голос
/ 26 февраля 2020

Вы, похоже, путаете разные политики планирования.

В Linux есть несколько политик планирования , которые определяют разные временные интервалы. Срез времени по умолчанию 100 мс равен только для политики SCHED_RR , которая используется для процессов в реальном времени. В действительности ни один нормальный процесс не выполняется под SCHED_RR.

Нормальные процессы работают под SCHED_OTHER, который является политикой планировщика по умолчанию. В соответствии с этим графиком временной интервал определяется динамически во время выполнения и значительно ниже. По умолчанию оно может составлять от 0,75 до 6 мс. Вы можете видеть эти значения по умолчанию (в наносекундах), определенные в kernel/sched/fair.c как sysctl_sched_min_granularity и sysctl_sched_latency соответственно. Вы можете получить реальные значения в вашей системе, прочитав /proc/sys/kernel/sched_min_granularity_ns или /proc/sys/kernel/sched_latency_ns.

. Подробнее о планировщике ядра CFS Linux можно узнать здесь (или здесь (больше документов).

0 голосов
/ 26 февраля 2020

в теории; это, возможно, намного хуже, чем вы думаете - если есть 100 других процессов, и каждый процесс потребляет максимально допустимый интервал времени (100 мс); затем может пройти 100 * 100 мс = 10 секунд, прежде чем процесс игры снова получит процессорное время.

Однако:

a) максимальная длина отрезка времени настраивается (при компиляции ядра) и (для настольных систем), скорее всего, будет 10 мс

б) процессы, которые потребляют максимально допустимый интервал времени, крайне редки. Если процессу дается максимум 10 мс, но он блокируется через 1 мс (потому что он должен ждать дискового ввода-вывода, или сети, или мьютекса, или ...), тогда процесс будет использовать только 1 мс

c) для современных компьютеров весьма вероятно, что имеется несколько процессоров

d) существуют другие политики планирования (см. http://man7.org/linux/man-pages/man7/sched.7.html), а также приоритеты задач ("nice") и " контрольные группы». Все это можно использовать для обеспечения того, чтобы специальный процесс (например, игра) получал процессорное время раньше других процессов и / или получал больше процессорного времени, чем другие процессы.

e) большинство людей, играющих в игры, просто не имеют другие процессы, потребляющие процессорное время одновременно, могут иметь несколько процессов, которые не используют процессорное время, но не будут иметь несколько процессов, пытающихся использовать 100% времени всех процессоров.

...