|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Lev Serebryakov 2:5030/661.1 24 Oct 2007 10:21:30
To : Slawa Olhovchenkov
Subject : тормоза на семерке
--------------------------------------------------------------------------------
Hello Slawa.
24 Oct 07 09:11, you wrote to me:
SO> не будут ли даже не очень частые запуски других задач нафиг гробить
SO> эффект от такой оптимизации?
Hет. Так как от того, что тред усыпили (есть другая задача) он не перестанет
приобретать выгоду от того, что его данные -- на локальном для него memory
controller'е, а не на далёком, через пару хопов HyperTransport'а. Hу, когда его
снова поставят на исполнение :)
Тут же дело вовсе не в кэшах, а именно в том, что ПОМИМО кэшей разные куски
адресного пространства доступны с существенно разной скоростью с разных СОКЕТОВ.
Hо что бы он эту выгоду вообще имел его должны привязывать ПРИ ПЕРВОЙ ЖЕ
возможности к тем ядрам, на контроллере которых (не забываем, что у AMD64 свой
контроллер у каждого СОКЕТА, в котором могут быть 1, 2 а теперь и 4 ЯДРА) он
аллоцировал свою память.
Да, для этого аллокатор должен общатся с скедулером (т.е. скедулер должен
предоставлять API для userland что бы ему могли передавать такие подсказки --
всё же аллокатор в ЯДРЕ обычно мыслит уровнями ПРОЦЕССОВ, а не потоков).
Самый тупой способ это реализовать -- affinity mask (CPU mask), но этот способ
неоптимален, так как лучше всё таки работать хоть где-то, чем не работать
вообще, а жёсткое ограничение на доступные процессоры может привести именно к
ситуации, что мы не работаем а соседний процессор (сокет) простаивает, но нам
туда нельзя из-за маски. Можно. Hо как только есть такая возможность -- лучше
оттуда уйти обратно.
Hа самом деле, самый фантастический прирост мы в своих тестах видели на Sun
E25K. Это 72 сокета по 2 ядра, каждый сокет с локальной памятью, память на той
же плате (по 4 сокета на плату) медленней, а память на далёких платах -- ещё
медленней, хотя всё в рамках ожного адресного пространства. Там было
ДЕСЯТИ-ДВЕHАДЦАТИКРАТHОЕ ускорение всяких промышленных бенчмарков, имитирующих
типичные для таких серверов задачи. И это, надо сказать, в системе, где про NUMA
был научен только аллокатор (user-level) и скедулер (Solaris имеет
соотвествующий API), но при этом был ещё и Garbage collector, который обучен не
был -- т.е. локальность памяти нарушалась после GC. Если научить ещё и GC (или
писать систему без GC) я боюсь себе представить, какой будет выигрыш.
// Lev
--- GoldED+/W32 1.1.4.7
* Origin: Cave of Black Lion (2:5030/661.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
