Линуксовое

[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]

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