Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1
RSS
IPC / NUMA-aware VM / POSIX Threads, а есть тут знающие столь тонкий вопрос?
 
1)чего лучше порекомендуете для IPC на FreeBSD? Гонять надо будет много данных между двумя процессами. Чего посоветуете?
shared memory vs unix sockets?

2)много ли профита можно получить переездом freebsd8 => freebsd9 (в 9ке вроде как сделали NUMA-aware VM) и влияет ли это на ответ в п.1 ?

3)Насколько плохо для производительности наличие большого количества(допустим, сотни) почти всегда спящих нитей(там i/o bound задача, нитки иногда просыпаются и тут же засыпают) ?
 
По второму вопросу такое соображение. Смысл NUMA разнесении тяжелых приложений по процессорам со своей локальной ОП. Для того, чтобы процессор читал только свою ОП и не обращался к соседской (с большими накладными расходами). На сколько я понимаю, в твоем случае, если разнести два процесса по разным ЦП, то выйдут только тормоза. Хуже чем SMP. Если же закрепить нити попарно и разнести пары равномерно по всем ЦП, то выигрыш, опять же, будет только если нити будут читать только локальную ОП. Это должен сделать гипервизор или ты сам.
 
Ну про то, что надо сделать для NUMA я в курсе :)) Раскидывать нити/процессы по NUMA-нодам должен планировщик. Другое дело, что в случае Linux штатный планировщик знает про топологию системы(не только принадлежность ядер к NUMA-нодам, но и являются ли логические ядра принадлежащеми одному ядру или же нет).

AFAIK, ULE3 во фре тоже в курсе про топологию, но насколько он в курсе NUMA - надо гуглить.
В принципе, можно и руками задать affinity mask при старте(там процессы стартуют парами, по факту - это просто родитель&потомок) и привязать их к одному ядру(чтобы снизить cache-miss'ы).

Вот кто бы на 3й пункт ответил =( По идее, если поток спит/заблокирован на i/o, то он не ставится планировщиком в очередь исполнения.
Страницы: 1
Читают тему