Как будут планироваться приложения на многоядерных компьютерах с поддержкой Hyper-Threading?

Question

Я пытаюсь лучше понять, как работают многоядерные процессоры с поддержкой многопоточности. Допустим, у меня есть приложение, которое можно скомпилировать с помощью MPI или OpenMP или MPI + OpenMP. Интересно, как это будет запланировано на CentOS 5.3 с четырьмя процессорами Xeon X7560 @ 2,27 ГГц, и в каждом ядре процессора включена технология Hyper-Threading.

Процессор пронумерован от 0 до 63 в / proc / cpuinfo. Насколько я понимаю, есть ЧЕТЫРЕ 8-ядерных физических процессора, общее количество ФИЗИЧЕСКИХ ЯДЕР - 32, на каждом ядре процессора включена технология Hyper-Threading, всего процессоров LOGICAL - 64.

1. Скомпилировано с MPICH2 Сколько физических ядер будет использовано, если я буду работать с mpirun -np 16? Распределяется ли оно между имеющимися 16 физическими ядрами или 16 логическими процессорами (8 физических ядер, использующих гиперпоточность)?

2. скомпилировано с OpenMP Сколько физических ядер будет использоваться, если я установлю OMP_NUM_THREADS = 16? Будет ли он использовать 16 процессоров LOGICAL?

3. Скомпилировано с MPICH2 + OpenMP Сколько физических ядер будет использоваться, если я установлю OMP_NUM_THREADS = 16 и запустлю с mpirun -np 16?

4. Скомпилировано с OpenMPI

OpenMPI имеет две опции времени выполнения

-cpu-set, который определяет логический процессор, выделенный для задания, -cpu-per-proc, который указывает количество процессоров для каждого процесса.

Если запустить с mpirun -np 16 -cpu-set 0-15, он будет использовать только 8 физических ядер?
Если запустить с mpirun -np 16 -cpu-set 0-31 -cpu-per-proc 2, как это будет запланировано?

Спасибо

Jerry

Answer 1

Я бы ожидал, что любой разумный планировщик предпочтет запуск потоков на разных физических процессорах, если это возможно. Тогда я ожидаю, что он предпочтет разные физические ядра. Наконец, если это необходимо, он начнет использовать второй поток с гиперпоточностью на каждом физическом ядре.

В основном, когда потоки должны совместно использовать ресурсы процессора, они замедляются. Таким образом, оптимальной стратегией обычно является минимизация объема совместного использования ресурсов процессора. Это правильная стратегия для процессов, связанных с процессором, и обычно ОС предполагает, что она имеет дело с этим.

Answer 2

Как видно из двух других ответов, идеальная политика планирования варьируется в зависимости от того, какую деятельность выполняют потоки.

Потоки, работающие с совершенно разными данными, выигрывают от большего разделения. Эти потоки в идеале должны планироваться в отдельных доменах NUMA и физических ядрах.

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

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

Принятие идеального решения о планировании зависит от сбора данных и принятия решений. Большая опасность в дизайне ОС состоит в том, чтобы сделать планирование потоков слишком умным. Если операционная система тратит много процессорного времени, пытаясь найти идеальное место для запуска потока, это напрасная трата времени, которое она может использовать для запуска потока.

Поэтому часто эффективнее использовать упрощенный планировщик потоков и, если необходимо, разрешить программе указывать свою собственную политику. Это настройка привязки потока.

Answer 3

Я бы рискнул предположить, что планировщик попытается сохранить потоки в одном процессе на тех же физических ядрах. Так что если бы у вас было шестнадцать потоков, они были бы наименьшим количеством физических ядер. Причиной этого будет локальность кэша; считается, что потоки из одного и того же процесса с большей вероятностью будут касаться одной и той же памяти, чем потоки из разных процессов. (Например, затраты на аннулирование строк кэша в разных ядрах высоки, но для логических процессоров в одном и том же ядре эта цена не возникает).