История изменений
Исправление vzzo, (текущая версия) :
Если вы такой понятливый, то может хоть вы объясните, каким образом переключение адресных пространств относится к переключению нитей в рамках одного процесса?
Вы говорили, что смена контекста дорога из-за того, что нужно сохранять регистры (хотя на самом деле это не так: даже при вызове обычной функции треть регистров сохраняется в память). Царь говорил, что смена контекста дорога из-за того, что нужно перенастраивать виртуальную память.
При переключении нитей перенастройка виртуальной памяти не требуется, из чего следует, что смена контекста между двумя нитями дешёвая.
В данном вопросе Царь прав.
Однако, линуксовый планировщик плохо дружит с большим количеством ожидающих выполнения нитей, а остальной линукс иногда от балды будит спящие по делу нити (см. spurious wakeup, или проблемы с epoll/accept после форков). Это пагубно сказывается на производительности. Спасает либо уверенность, что треды большую часть времени будут заблокированы на IO и не попадут в очередь на выполнение большим скопом (что показал тот сервер с 10к нитями, но что при очень интенсивном IO и дорогих multiqueue карточках не до конца верно), либо волшебство вроде переключения нити в обход планировщика и принудительный саспенд нити до такого переключения. Последнее волшебство уже начинает сильно напоминать зелёные треды.
Исходная версия vzzo, :
Если вы такой понятливый, то может хоть вы объясните, каким образом переключение адресных пространств относится к переключению нитей в рамках одного процесса?
Вы говорили, что смена контекста дорога из-за того, что нужно сохранять регистры (хотя на самом деле это не так: даже при вызове обычной функции треть регистров сохраняется в память). Царь говорил, что смена контекста дорога из-за того, что нужно перенастраивать виртуальную память.
При переключении нитей перенастройка виртуальной памяти не требуется, из чего следует, что смена контекста между двумя нитями дешёвая.
В данном вопросе Царь прав.
Однако, линуксовый планировщик плохо дружит с большим количеством ожидающих выполнения нитей, а остальной линукс иногда от балды будит спящие по делу нити (см. spurious wakeup, или проблемы с epoll/accept после форков). Это пагубно сказывается на производительности. Спасает либо уверенность, что треды большую часть времени будут заблокированы на IO и не попадут в очередь на выполнение большим скопом (что показал то сервер с 10к нитями, но что при очень интенсивном IO и дорогих multiqueue карточках не до конца верно), либо волшебство вроде переключения нити в обход планировщика и принудительный саспенд нити до такого переключения. Последнее волшебство уже начинает сильно напоминать зелёные треды.