1

Я запускаю параллельный алгоритм, используя светлые потоки, и мне интересно, как они назначаются для разных ядер, когда система предоставляет несколько ядер и несколько микросхем. Связаны ли потоки с одним чипом, пока все ядра на чипе не будут исчерпаны? Связаны ли потоки с ядрами на разных микросхемах, чтобы лучше распределить работу между фишками?Каковы потоки легкого веса, запланированные ядром linux на многопроцессорной многоядерной SMP-системе?

+0

Какую библиотеку нитей вы используете? – sarnold

+0

Мы используем pthreads. – rreyes1979

+0

Является ли библиотека поведения зависимой? Подумайте о тех деталях, которые обрабатываются планировщиком ядра. – rreyes1979

ответ

3

Вы не говорите, на какой ОС вы находитесь, но в Linux потоки привязаны к ядру, основанному на нагрузке на это ядро. Поток, который готов к запуску, будет привязан к ядру с наименьшей нагрузкой, если вы не укажете иначе, установив привязанность потоков. Вы можете сделать это с помощью sched_setaffinity(). Дополнительную информацию см. На странице руководства. В общем, как сказал meyes1979, это то, что решается планировщиком, реализованным в используемой вами ОС.

В зависимости от версии Linux, которую вы используете, есть две статьи, которые могут быть полезны: this article describes early 2.6 kernels, up through 2.6.22 и this article describes kernels newer than 2.6.23.

+0

Спасибо за ваш ответ. Да, ОС - Linux. – rreyes1979

+0

благодарит @sarnold за обновленную ссылку – kch

+0

Позвольте мне посмотреть, получаю ли я это: нить назначается ядру с наименьшей нагрузкой, но вы можете установить сходство потоков, чтобы «предложить» ядро. Теперь я подумал, что поток, как правило, был привязан к тому ядру, в котором он уже работал, чтобы избежать промахов в кэше. Итак, если это так, поток пытается оставаться на ядре, в котором он начал работать, но если ядро ​​занято, то оно может «мигрировать» на другое, чтобы загрузить баланс. Я что-то упускаю? – rreyes1979

0

Различные библиотеки потоковой обработки выполняют операции по резьбе по-разному. «Стандартом» в Linux в наши дни является NPTL, который планирует потоки на том же уровне, что и процессы. Это довольно хорошо, так как процесс создания быстро работает на Linux, и он всегда должен оставаться быстрым.

Ядро Linux пытается обеспечить очень сильное сходство процессора с выполнением процессов и потоков, чтобы увеличить отношение кэш-промахов к промахам кеша - если задача всегда выполняется на одном и том же ядре, скорее всего, будет иметь предполетную кэш-строки.

Это, как правило, хорошо, но я заметил, что ядро ​​может не всегда переносить задачи из загруженных ядер на незанятые ядра. Такое поведение может меняться от версии к версии, но я обнаружил, что все задачи, связанные с процессором, выполняются на одном ядре, а три других ядра простаивают. (Я нашел это, заметив, что одно ядро ​​было на шесть или семь градусов по Цельсию теплее, чем другие три.)

В общем, правильная вещь должна произойти; но когда ядро ​​не выполняет автоматическую перенос задач на другие процессоры, вы можете использовать команду taskset(1), чтобы ограничить разрешенные процессоры, или вы можете изменить свою программу, чтобы использовать функцию pthread_setaffinity_np(3), чтобы попросить перенести отдельные потоки. (Это, пожалуй, лучше всего подходит для внутренних приложений - один из ваших пользователей может не хочу вашей программы, чтобы использовать все доступные ядра. Если вы предпочитаете включать вызовы этой функции в свою программу, убедитесь, что она настраивается через конфигурацию файлы для обеспечения функциональности, аналогичной программе taskset(1).)

+0

Хорошая точка в Linux, сохраняющая тайники в теплом виде (видимо, в буквальном смысле). [Здесь] (http://littledaemons.wordpress.com/2009/01/22/cpu-affinity-and-taskset/) - это еще одно обсуждение этого вопроса для ссылки OP. – kch