Какой из них больше влияет на производительность IPC? переключение контекста или количество процессов?

Question

По моему мнению, когда речь идет об улучшении производительности IPC или о снижении задержек, переключение контекста представляется наиболее важным фактором. Но мне всегда было интересно, почему я никогда не слышал, что количество запускаемых процессов также является фактором?

Если я правильно понимаю, переключение контекста может быть выполнено аппаратно для большинства современных процессоров, что должно значительно сократить время, затрачиваемое на это. С другой стороны, процессорное время распределяется между всеми работающими процессами в системе. Чем более работоспособна обработка в системе, тем реже процесс получает возможность получить контроль над процессором. (Хотя в большинстве случаев большинство процессов должно находиться в состоянии сна в течение большей части времени, но это просто необоснованное предположение о системе, которое, я думаю, не может применяться ко всем возможным случаям.)

Предположим, например, что система настроена на циклический планировщик, 1 мс времени и 7 выполняемых процессов с тем же приоритетом, как указано ниже:

    P1 P2 P3 P4 P5 P6 P7

По определению циклического планирования порядок переключения контекста должен быть следующим:

    P1 -> P2 -> P3 -> P4 -> P5 -> P6 -> P7 -> P1 -> P2 -> ... -> P6 -> P7 -> P1 -> P2 -> ... -> P7 -> P1 -> ... and so on

Из-за вышеуказанного порядка переключения контекста, если P1 попытается отправить сообщение через какой-либо механизм IPC на P5, сообщение будет обработано P5 через 3 мс спустя. Это связано с тем, что P5 необходимо дождаться, пока P2, P3 и P4 израсходуют свой собственный временной интервал, чтобы в конечном итоге P5 был запланирован для запуска и обработки сообщения, отправленного P1. Таким образом, задержка IPC в данном случае составляет не менее 3 мс, что намного больше, чем время, необходимое для переключения контекста (которое обычно составляет порядок мкс)! Если P5 хочет дать ответ относительно сообщения, отправленного P1, потрачено еще 2 мс, потому что P6 и P7 должны закончить свой ход заранее. А время задержки в оба конца ( https://en.wikipedia.org/wiki/Round-trip_delay_time) должно быть: 3 мс + 2 мс = 5 мс!

Если число запускаемых процессов увеличивается следующим образом:

    P1 P2 P3 ... P99 P100

задержка IPC для отправки сообщения с P13 на P57 будет: (57 - 13 - 1) мс = 43 мс

Итак, в заключение... Существует ли проблема, описанная выше? Будет ли учитываться количество выполняемых процессов при тестировании или измерении производительности для IPC? Или почему количество выполняемых процессов в системе не имеет значения с точки зрения производительности / задержки IPC?

Answer 1

Попробуй хакбенч. Интересно увидеть результаты. Несмотря на тестирование планировщика, вы можете изменить код для сравнения IPC.

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

http://www.makelinux.net/man/8/H/hackbench

Если вам нужен IPC другого типа, чем каналы и сокеты, вы можете изменить исходный код Hackbench.