LINUX.ORG.RU

SMP системы


0

0

Здравствуйте. 
Собственно у меня два вопроса:
1) Можно ли в SMP системах как нибудь узнать на каком
   процессоре(ядре) работает процесс(поток)?
2) Можно ли процессу (потоку) назначит процессор(ядро) 
   на котором он будет работать?
anonymous

Ответ на: Re: SMP системы от vden

Re: SMP системы

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

anonymous ()

Re: SMP системы

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

anonymous ()

Re: SMP системы

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

anonymous ()
Ответ на: Re: SMP системы от stassats

Re: SMP системы

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

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

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

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

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

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

anonymous ()
Ответ на: Re: SMP системы от anonymous

Re: SMP системы

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

gettid()

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

anonymous ()
Ответ на: Re: SMP системы от anonymous

Re: SMP системы

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

anonymous ()
Ответ на: Re: SMP системы от anonymous

Re: SMP системы

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

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

cvv ★★★★★ ()
Ответ на: Re: SMP системы от cvv

Re: SMP системы

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

Почему?

Ximen ★★★★ ()
Ответ на: Re: SMP системы от cvv

Re: SMP системы

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

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

anonymous ()
Ответ на: Re: SMP системы от cvv

Re: SMP системы

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

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

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

anonymous ()
Ответ на: Re: SMP системы от anonymous

Re: SMP системы

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

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

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

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

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

cvv ★★★★★ ()
Ответ на: Re: SMP системы от cvv

Re: SMP системы

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

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: Re: SMP системы от anonymous

Re: SMP системы

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

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

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

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

cvv ★★★★★ ()
Ответ на: Re: SMP системы от cvv

Re: SMP системы

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

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

Ну NPTL тоже 1:1

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

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

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

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

anonymous ()
Ответ на: Re: SMP системы от anonymous

Re: SMP системы

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

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

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

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

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

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

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

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

cvv ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.