[linux]: двухъядерный процессор
Утилитой taskset. Ключевые слова — cpu affinity.
Посмотреть сколько ядер можно в /proc/cpuinfo
Посмотреть сколько ядер можно в /proc/cpuinfo
а зачем привязывать? оно само распределится лучшим образом.
Спасибо. Я там и смотрю, а как отличить двухъядерный проц от двух процессоров?
[localhost ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Pentium(R) D CPU 3.00GHz
stepping : 2
cpu MHz : 3012.109
cache size : 2048 KB
physical id : 0
siblings : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx
fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid xtpr
bogomips : 5931.00
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Pentium(R) D CPU 3.00GHz
stepping : 2
cpu MHz : 3012.109
cache size : 2048 KB
physical id : 0
siblings : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx
fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid xtpr
bogomips : 6012.92
а зачем привязывать? оно само распределится лучшим образом.совершенно необязательно. Например, если у нас есть расчетная задача, у которой инструкции помещаются в кеш L1, а данные - в L2, мы получим заметный прирост, реже дергая оперативку во время переключений контекста
Intel(R) Pentium(R) D CPU 3.00GHzУ тебя двухядерный, кеш L2 у каждого ядра свой (т.е. фактически можно считать, что просто два процессора на одном кристалле)
нормальные планировщики прекрасно об этом знают и не будут зря таскать задачи по ядрам.
другое дело что там можно повысить предсказуемость времени расчёта, но не факт что его уменьшить.
другое дело что там можно повысить предсказуемость времени расчёта, но не факт что его уменьшить.
в разных случаях — по-разному. Планировщик, каким бы он ни был, достаточно часто ошибается
ты наверно судишь по виндовому — он просто ужасен, там действительно проще руками раскидать по ядрам.
не забывай, на работе у меня Linux. Я сужу по всяким планировщикам
но с двумя процессами на двух ядрах линуховый планировщик уж как-нить справится =)
-- если какой-то процессор простаивает, выбирается его очередь на выполнение. предпочитается сначала процессор, ранее выполнявший процесс, а затем — локальный процессор.вот я не совсем понимаю: если в системе крутится только один прожорливый пакетный процесс, то почему бы ему прямо на первом шаге не перейти на локальный процессор с предыдущего, если локальный изредка выполнял обработку какой-нибудь фигни типа нажатий пользователя на кнопочку или там по крону что-нибудь делал.
— если рабочая нагрузка процессора, выполнявшего процесс последним, значительно ниже, чем у локального процессора, выбирается прежняя очередь на выполнение.
— если процесс выполнялся недавно, выбирается прежняя очередь на выполнение (из соображений кэша)
— если перенос процессора на локальный уменьшает дисбалланс, выбирается локальный
Я вот такой эффект имел ввиду, когда говорил, что не всегда стандартные планировщики рулят.
Цитата:
Цитата:
Занятный момент — N ядер могут дать даже более чем N-кратный прирост скорости. Этот феномен называется Supra-linear scaling.Правда, там несколько потоков, а не процессов, но не суть. Идея в том, что если привязать потоки к ядрам, цифра 6.27 появляется, а если не привязывать — получается чо-то вроде 4-х.
Хороший пример можно поглядеть здесь: Supra-linear Packet Processing Performance with Intel® Multi-core Processors
На 4-ёх ядерном процессоре авторы получили ускорение в 6,27 раза. Причём на вполне реалистичном приложении — сетевой сервер для фильтрации TCP соединений.
И в ряде других источников я встречался с упоминаниями этого феномена, правда с более скромными результатами (ссылки сейчас будет трудно найти).
Основная причина этого феномена — размер кэша первого и второго уровней. Если рабочий набор (и данных и команд) начинает не влезать в кэш первого уровня, то появляется скачкообразное падение производительности до 10-15 раз. И аналогично для не влезания в кэш второго уровня. На многоядерных процессорах кэши больше (пропорционально числу ядер соотв. рабочий набор может начать влезать в кэш, в который он раньше не влезал. В этом и кроется причина Supra-linear scaling.
Хотя возможно тут есть и ещё какие-то менее очевидные факторы.
Конечно, цифра 6,27 достаточно большая, и, видимо, авторы, ну так скажем, создали благоприятные условия для проявления эффекта. На реальных приложениях такой цифры скорее всего добиться будет достаточно сложно. Однако, я думаю, что и можно создать искуственный пример, в котором добиться цифры 10.
если все ядра загружены равномерно, то планировщик ядра линукс будет все оставлять согласно кешам, то есть эффект будет именно такой, как описан. другое дело, если загрузка ядер/процессоров неравномерная. что будет тогда — мне не понятно.
под прожорливостью я имел в виду требования к памяти.
если неравномерная то изредка будут переключения между ядрами для равномерного нагрева.
если все ядра загружены равномерно, то планировщик ядра линукс будет все оставлять согласно кешамразделяя выполнение программы на стадии, почти никогда не удается сделать их одинаковыми. Конвейер же двигается со скоростью самой медленной части. Т.е. довольно ощутимое время (5-10%) часть ядер будет простаивать. И планировщик может попытаться перекинуть на них то, что исполняется на других ядрах. Иногда это сработает, в этом случае — не срабатывает.
Еще одной прикольной фишкой многоядерного конвейера является то, что каждой части можно гарантировать, что она исполняется одна, поэтому можно уйти от синхронизации (еще одна причина для ускорения). Однако при перекидывании стадии с ядра на ядро придется выполнить Memory Barrier, т.е. синхронизировать кеш разных ядер. Это заметно ударяет по производительности (чо-то порядка 100 тактов простоя).
ну ты уже немного про другое, такой конвейер конечно всегда надо раскидывать
понятно, только не понял, как это с моим вопросом связано. а что такое конвейер в данном случае? 
твой вопрос я слегка не понял, отвечал на другое. Ты откуда взял цитату про планировщик?
из "Understanding Linux Kernel" по памяти процитировал. =)
это все делается в функции try_to_wake_up которая процессы будит.
это все делается в функции try_to_wake_up которая процессы будит.
ну ты уже немного про другое, такой конвейер конечно всегда надо раскидыватьмб. Я просто привел пример, когда планировщик только мешается. Во многих остальных случаях он работает хорошо.
хотя эта функция вызывается только если процесс чего-то ждал и у него был высокий приоритет.
а для всяких математических рассчетов или компиляции ядро приоритет обычно понижает.
а если приоритет низкий, планировщик вызывается через какое-то количество тиков совершенно иной функцией и она может быть не имеет того недостатка, что может отправить требовательный к кешу процесс на другое ядро. этого я не помню, щас почитаю про это.
а для всяких математических рассчетов или компиляции ядро приоритет обычно понижает.
а если приоритет низкий, планировщик вызывается через какое-то количество тиков совершенно иной функцией и она может быть не имеет того недостатка, что может отправить требовательный к кешу процесс на другое ядро. этого я не помню, щас почитаю про это.
сорри, проглядел про taskset
еще например schedtool можно
еще например schedtool можно
Оставить комментарий
Jackill
Есть компьютер с двухъядерным процессором. Хочется запустить 2 процесса, каждый из которых считался бы на своём ядре. Кто-нибудь знает как это сделать?PS: может быть на этом компе и два процессора, а не один двухъядерный. Я не знаю как точно определить.