Поведение упрощенных процессов с новым PID
sysfs — это виртуальная файловая система. На самом деле он не существует на диске, поэтому (дисковый )ввод-вывод отсутствует. Также нет никакого ввода-вывода, даже виртуального, за исключением случаев, когда что-то читает файл. Это просто API ядра, который открывается пользовательскому пространству через open/ read/ write/ closeвместо, например, добавления еще одного системного вызова.
Вероятно, есть крошечные накладные расходы. Безусловно, требуется тривиальный бит памяти для хранения счетчиков, тривиальное количество процессорного времени для их обновления и тривиальное увеличение размера образа ядра.
OTOH, если на вашем компьютере используется масштабирование частоты, его отключение значительно снизит вашу способность исследовать его поведение, а снижение частоты ЦП в нужное время обычно оказывает большое влияние как на производительность, так и на срок службы батареи.
One thing that I noticed when running strace that the Futex usage exploded by the factor of 8-10. Could the LWP's be a major the cause of that? [...], but I thought that LWP share the same memory space, so there should not be an explosion in the Futex usage.
Да, использование LWP, скорее всего, приведет к увеличению использования фьютексов, поскольку они на самом деле предназначены именно для этого случая — синхронизации различных потоков, использующих одну и ту же память.
Фьютексы используются для медленного пути любых операций блокировки, когда есть общая память, LWP или поток сообщают ядру о блокировке до тех пор, пока не будет получено уведомление о том, что блокировка была разблокирована.
Быстрый путь использует атомарные операции. (ЦП атомарно увеличивает или уменьшает значение счетчика, чтобы он мог определить, был ли он первым, кто заблокировался, или последним, кто разблокировал ), чтобы не было необходимости выполнять системные вызовы на быстром пути..
Увеличение количества конфликтов за блокировку означает, что будет выполняться больше операций фьютексов, что, вероятно, повлияет на производительность не только из-за самих системных вызовов, но и потому, что когда вызываются фьютексы, это означает, что некоторые LWP или потоки находятся в спящем режиме в ожидании ресурсов.
Код в glibc будет знать об использовании нескольких потоков или LWP, поэтому даже если в вашем коде нет явных блокировок, они будут в системных библиотеках, и в результате у вас может возникнуть конфликт блокировок,возможно замедление вашей программы, как описано.
It degrades quite a bit ( processing slows down by 30% ).
Другим фактором, когда у вас есть много потоков, совместно использующих память, является то, что в -структурах памяти ядра есть также некоторые структуры памяти, которые имеют грубые блокировки и также могут вызвать конфликт блокировок.
В частности, mmap_sem, который необходимо блокировать для записи каждый раз, когда вы сопоставляете больше областей памяти с вашим процессом. (В частности, это может вызвать выделение большего объема памяти с помощью malloc()и друзей .)
Now I was reading that LWP's can be scheduled and priorities assigned to them (I did not try either). Would this help the performance?
Возможно... Трудно сказать. Вы должны были бы сравнить.
Если то, что вы видите, является конкуренцией за блокировку, и если она обобщается через ваши кодовые пути (, не локализованные на один или несколько LWP ), то это вряд ли поможет.
Вы можете использовать инструментperf, чтобы понять производительность набора процессов в Linux. Он может показать вам горячие точки, а также показать, существуют ли горячие точки ядра.
Are there any tricks or best practices that should be followed when using LWP's or deciding to use them?
Для LWP или потоков, при использовании очень большого их количества, реализация malloc()становится весьма важной, так как есть обе проблемы, связанные с ядром (расширение отображений памяти вызывает потенциальную конкуренцию mmap_sem), так как проблемы в пользовательском пространстве (с использованием одной арены для всех потоков означают, что вам нужна блокировка, чтобы зарезервировать для них место.)
Некоторые библиотеки malloc были написаны для повышения производительности в сценариях, где используется массивная многопоточность. Например, tcmalloc или jemalloc . Принять их обычно просто (просто свяжите дополнительную библиотеку в )и может дать значительный прирост производительности, если это действительно ваше узкое место. Как всегда, тест, чтобы узнать, помогает это или нет.
Would forking be a better or a worse option from the performance standpoint?
Возможно, лучше. Трудно сказать, вам нужно сравнить, чтобы увидеть, лучше ли в вашем конкретном случае.
То же, что и для внедрения LWP,Вы должны сравнить, чтобы сказать, действительно ли это того стоит или нет.
Как описано выше, использование общей памяти между LWP или потоками (или наличие большего количества LWP или потоков, совместно использующих одну и ту же память ), увеличивает вероятность конфликта блокировок (, и даже если у вас нет явных блокировок, glibc и ядро будут. )Так что вполне возможно, что LWP на самом деле замедляют работу.
Я был свидетелем случая, когда многопоточное -приложение работало слишком медленно. Разработчик изменил его, чтобы использовать один поток, а не 40 потоков. Приложение внезапно увеличило скорость на 1000%. Оказалось, что он проводил 90% своего времени в борьбе за блокировку!