Линуксовое

[tobotras]

У линукса есть несколько механизмов ограничить процесс в доступных процессорных ядрах. Как минимум, cgroup и taskset. Если процессу важно знать, сколько у него ядер (чтобы сконфигурировать thread pool или ещё зачем-нибудь), то наивный способ -- прочитать /proc/cpuinfo. Он неправильный. Менее наивный -- позвать sysconf(_SC_NPROCESSORS_ONLN). Он тоже неправильный. Правильный -- вот:

  long num_processor_configured = sysconf (_SC_NPROCESSORS_CONF); /* list the number of processors configured */
  long num_processor_available;
  cpu_set_t mask;

  if (sched_getaffinity(0, sizeof(cpu_set_t), &mask) == 0) {
	num_processor_available = CPU_COUNT(&mask);
  } else {
	num_processor_available = sysconf(_SC_NPROCESSORS_ONLN);
  }

Comments

[drf-ckoff.livejournal.com]

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

[ostapru.livejournal.com]

Ну, например, всякие считалки/процессилки.
Запускать нитей больше, чем доступное количество ядер не имеет смысла. Поэтому getaffinity и запуск нитей на все доступные ядра.
Как в этом случае переписать, чтобы учитывать изменение количества ядер? Постоянно дергать getaffinity?

[drf-ckoff.livejournal.com]

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

[tobotras]

Гхм. Если количество ядер неограничено, то есть класс задач, когда плодить треды имеет смысл именно неограниченно.

[ostapru.livejournal.com]

Так оно работает хреново. Если задача хорошо параллелится и синхронизация минимальна, то больше чем поток на ядро - тут же сажает производительность.

[tobotras]

Ну, нифига. Все тред пулы осмысленно делать с оглядкой на количество процессоров.

[http://users.livejournal.com/_slw/]

линуксятина какая-то
пороть на конюшне

[ostapru.livejournal.com]

На виндах оно примерно также. Только вызов будет GetProcessAffinityMask().

[http://users.livejournal.com/_slw/]

т.е. ты даже не понял, за что пороть?

[tobotras]

Ты бы лучше снизошёл и объяснил.

[http://users.livejournal.com/_slw/]

нехорошо пользоваться менее переносимым апи при наличии более переносимого
я про pthread_getaffinity_np, например

[tobotras]

Что, по-твоему, означают буквы «np»?

[http://users.livejournal.com/_slw/]

по факту, sched_getaffinity кроме линуха нигде нет, в отличии от pthread_getaffinity_np

[ostapru.livejournal.com]

Ну pthread, так pthread.
IMHO, если задача переносимости не ставится, то лучше использовать родной API.

[http://users.livejournal.com/_slw/]

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

[tobotras]

Ну, по моему факту, ничего, кроме линуха, нигде нет :-P

[http://users.livejournal.com/_slw/]

да ну, это линуха нет

[alec_v.livejournal.com]

Количество ядер может ВНЕЗАПНО поменяться, если виртуалка по-живому мигрируется в облаке на другую материнку.

[tobotras]

Ну, значит, надо регулярно проверять, не поменялось ли :) Но сжимать thread pool — то ещё развлечение. Я б забил :)

[tobotras]

Оно может и вышеупомянутыми средствами ВНЕЗАПНО поменяться безо всяких виртуалок.

[d1f.livejournal.com]

А как это правильно сделать из шелла?
Мне нужно знать N для make -jN.

[tobotras]

А никак :) Ну, грепать /proc/cpuinfo или /proc/stat. Но см. выше про taskset/cgroup.