Как Линукс управляет памятью?

Если даже и нет, то ты можешь их дописать... обрати свой взор на top500.org

Вопрос надо ставить так: "а железо такое позволяет?"

Конкретизируем: Xeon 5400.

NUMA это называется и линукс такое умеет. При должной поддержке со стороны железа, естественно. Смотри в эту сторону.

Ясно, спасибо. Xeon 5400 это не нума...

> Xeon 5400 это не нума...

Совершенно верно, там классическая FSB. Вся память с точки зрения процессоров совершенно одинакова, весь траффик летит через северный мост. Хоть уставься, вся память видна всем процессорам одинаково (если, конечно, речь идет о СМП).

На Зеонах 7xxxx серии Бимеры ухитряются клепать НУМУ на своих фирменных чипсетах, но это уже совсем другая история.

В документации на мат. плату написано, что каждый из двух процессоров одключен к памяти через свой branch, который в свою очередь объединяет два банка памяти по 4 дима в каждом. Пропускная способность бранча 8.4Гб/с. У меня в программе получается примерно 8 гиг/сек на 8-ми потоках, т.е. по потоку на ядро.

Вопрос, можно ли от системы получить 8x2 гиг/сек? Или оно так не параллелится?

> В документации на мат. плату написано, что каждый из двух процессоров одключен к памяти через свой branch, который в свою очередь объединяет два банка памяти по 4 дима в каждом.

Что за чипсет? Если Seaburg (i5400), то там FSB каждого процессора втыкается в MCH, и их в чипсете поддерживается, действительно, две. И бранча там тоже два, по два канала на бранч, но к FSB они никакого отношения не имеют.

> Вопрос, можно ли от системы получить 8x2 гиг/сек?

Сильно зависит от условий.

Если каждая корка читает данные с различного чиипа, да еще и бранчи по FSB правильно распределились, то может. Но в природе этого не произойдет. И на запись это тоже не случится.

Это ж не НУМА, вся память считается абсолютно симметричной, у операционки нет способа контролировать аффинити, все дается на откуп MCH.

Если вдруг все корки работают с одной микросхемой, то имеем всего 4.25 гига/канал, и все, теоретический потолок...

> Это ж не НУМА, вся память считается абсолютно симметричной

Что-то есть подозрение, что у NUMA память тоже получается симметричной, по крайней мере в описании HP. Чо с неё толку, если она данные между процессорными досками распространяет при записи?

> Чо с неё толку, если она данные между процессорными досками распространяет при записи?

8-/? А как еще можно память распределять?

Обычно по умолчанию память в НУМЕ максимально аффинна тому процу, который попросил кусочек. Но есть сисколлы, явным образом задаюшие аффинити текущего процесса.

То есть, контроль над аффинностью полный. Ну, а если уж память куды прописалась, мигрировать сама она никак не может -- в НУМЕ память всегда принадлежит какому-то определенному процессору (ок, нескольким, там тоже небольшая FSB мелькает).

> Что за чипсет? Если Seaburg (i5400), то Он самый

> Если вдруг все корки работают с одной микросхемой, то имеем всего 4.25 гига/канал, и все, теоретический потолок...

Понятно. У меня так и получается. 4 потока на одном процессоре как-раз получают где-то 4 гиг/сек. Надо попробовать привязать потоки 2x2, глядишь, 8 выйдет...

>Что-то есть подозрение, что у NUMA память тоже получается
>симметричной, по крайней мере в описании HP. Чо с неё толку, если она
>данные между процессорными досками распространяет при записи?

Там же на HP есть гайд как правильно писать программы под NUMA.

> Обычно по умолчанию память в НУМЕ максимально аффинна тому процу, который попросил кусочек. Но есть сисколлы, явным образом задаюшие аффинити текущего процесса.

Есть-то они есть, да не всегда про нашу честь: http://docs.hp.com/en/4913/ccNUMA_White_Paper.pdf

> Там же на HP есть гайд как правильно писать программы под NUMA.

Если гайд стоящий и ссылка под рукой есть - поделись. Особенно интересует классификация и диагностика проблем связанных с NUMA.

>под рукой есть - поделись
К сожалению под рукой нет. Просто изучал ресурсы HP, по вопросу почему наш софт на супер архитектуре работает медленнее чем на древнем SMP, там и наткнулся на пару документов гайд по оптимизации существующего кода под NUMA и писание под NUMA.

> Есть-то они есть, да не всегда про нашу честь: http://docs.hp.com/en/4913/ccNUMA_White_Paper.pdf

Шутим?

Мануал датирован 2003 годом и описывает ситуацию двухгодичной (на тот момент) давности. С ядра 2.5 все есть.