SMP системы

Да, можно. sched_getaffinity() - узнать, sched_setaffinity() - установить.

Вот пример работы с ними: http://www.linuxjournal.com/articles/lj/0111/6799/6799l1.html

спасибо тебе vden. То что надо.

Еще один вопросик. А как узнать кол-во процессоров ?

Я так понял , функции sched_getaffinity и sched_setaffinity работают с процессами , а что нибудь подобное для потоков?

Поток суть и есть процесс.

>Поток суть и есть процесс.

Функции sched_setaffinity, sched_getaffinity в качестве одно из аргументов принимают pid процесса.

И как мне получить pid потока?

Спрошу проще.

Есть процесс создающий два потока , можно ли сделать так что бы потоки гарантированно исполнялись на разных процессорах?

А еще лучше что бы можно было самому выбирать на каком процессоре будет работать поток?

>И как мне получить pid потока?

gettid()

Насчет количества процессоров, прочитай файл /proc/cpuinfo. Ничего плохого в этом нет, т.к. sched_setaffinity, sched_getaffinity все равно linux specifiс.

Все теперь ясно. Больше всем спасибо.

>Есть процесс создающий два потока , можно ли сделать так что бы потоки гарантированно исполнялись на разных процессорах?

есть авторитетное мнение что на суперскалярной архитектуре, в часности x86, это безсмысленно

> есть авторитетное мнение что на суперскалярной архитектуре, в часности x86, это безсмысленно

Почему?

>есть авторитетное мнение что на суперскалярной архитектуре, в часности x86, это безсмысленно

мне тоже очень интересно почему же это все таки бессмысленно?

> есть авторитетное мнение что на суперскалярной архитектуре, в часности x86, это безсмысленно

Эээ. С каких пор на суперскалярных процессорах кеш не инвалидируется? ;-)

На многоядерниках с общим L2/L3 эффект, конечно, будет сглаженным, а на "просто smp", а тем более на NUMA ручное управление привязкой процессов может дать серьезный выигрыш; но, правда, только в случаях, когда ядерный планировщик тупит (ну там, перебрасывает тред с проца на проц каждый тик, или ставит треды "далеко" от потребляемой ими памяти на NUMA). А бывает такое не то, чтобы очень часто; да и руками можно напортачить (скажем, на 2xOpteron2xx я вполне верю в ситуацию, когда зашедулить оба треда на тот проц, к которому ближе память, и оставить второй простаивающим будет быстрее, чем поделить поровну).

>а на "просто smp", а тем более на NUMA ручное управление привязкой процессов может дать серьезный выигрыш;

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

А вот в случае с тредами можем ликвидировать инвалидирование кешей.

Треды - это всего лиш способ обойти блокирование на сисколах и К.

в нума я не ориентируюсь - в живую не щупал/не игрался.

> >а на "просто smp", а тем более на NUMA ручное управление привязкой процессов может дать серьезный выигрыш;

> я не думаю что реально надыбать ситуацию когда ручное управление привязкой процессов даст выигрыш хоть в чём нибуть.

> А вот в случае с тредами можем ликвидировать инвалидирование кешей.

> Треды - это всего лиш способ обойти блокирование на сисколах и К.

С т.з. ядерного планировщика в линуксе треды от процессов не так уж сильно отличаются (чтобы не сказать "это одно и то же".

А привязка процессов может помочь когда шедулер с ума сходит (я такое видел - запущенный в 4 процесса расчет перебрасывало с проца на проц постоянно. Правда, это была 5-я фряха...).

> в нума я не ориентируюсь - в живую не щупал/не игрался.

из чисто теоретических соображений, когда у тебя машинка устроена как

mem1<->cpu1<->cpu2<->mem2

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

>С т.з. ядерного планировщика в линуксе треды от процессов не так уж сильно отличаются (чтобы не сказать "это одно и то же".

В бытность LinuxThread так и было. При NTPL - не в курсе; а вот с точки зрения кешей эт далеко не одно и тоже :)

>А привязка процессов может помочь когда шедулер с ума сходит (я такое видел - запущенный в 4 процесса расчет перебрасывало с проца на проц постоянно. Правда, это была 5-я фряха...).

Представил ручную привязку процессов на SMP с 4000 ядер... мда

> > С т.з. ядерного планировщика в линуксе треды от процессов не так уж сильно отличаются (чтобы не сказать "это одно и то же".

> В бытность LinuxThread так и было. При NTPL - не в курсе;

Ну NPTL тоже 1:1

> а вот с точки зрения кешей эт далеко не одно и тоже :)

Это с какой стороны посмотреть: если "единицу исполнения" переносит на другое ядро - то она стартует с пустого кеша независимо от того, процесс это или тред.

> Представил ручную привязку процессов на SMP с 4000 ядер... мда

А что, кто-то использует на таких машинках Single System Image системы? Мне всегда казалось, что они устроены как "по ядру на ящик/матплату, кластерная FS и MPI", с некоторыми вариациями.

>> а вот с точки зрения кешей эт далеко не одно и тоже :)

>Это с какой стороны посмотреть: если "единицу исполнения" переносит на другое ядро - то она стартует с пустого кеша независимо от того, процесс это или тред.

я имел ввиду что вероятность инвалидации кешей при использование тредов как минимум на порядок выше чем при использовании процессов изза общего адресного пространства

>> Представил ручную привязку процессов на SMP с 4000 ядер... мда

>А что, кто-то использует на таких машинках Single System Image системы? Мне всегда казалось, что они устроены как "по ядру на ящик/матплату, кластерная FS и MPI", с некоторыми вариациями.

не все задачи ложатся на кластер. Периодически требуется SSI

пользую в основном американские военные/учёные. Производит естественно только SGI.

PS: 4000 ядер эт экспериментальная железка. В жизнь пока пускают только с 2000 ядер.