Anatoly MoskovskyКстати VirtualAllocExNuma собственно выделяет не физическую память, а виртуальную память и помечает что она относится к заданному узлу .
А что значит "она относится к заданному узлу", и что будет если начать её использовать из другого узла?

Anatoly MoskovskyА при первом обращении к ней уже выделяется физическая память.
Поэтому вы можете выделять ею намного больше чем доступно физ. памяти не только на одном узле, но и вообще в системе.
А например когда такое поведение может понадобиться и зачем выделять памяти больше чем её есть?

Anatoly Moskovskyиспользовать из другого узлаА что значит "она относится к заданному узлу", и что будет если начать её использовать из другого узла?
Это значит "при попытке обратиться к странице с любого узла - выделить ее на заданном" :)
А если на выделенном узле нет столько физической памяти? :)

Anatoly Moskovskyиспользовать из другого узлаА например когда такое поведение может понадобиться и зачем выделять памяти больше чем её есть?
Мало ли когда. Я вообще писал что это возможно, а не что так и надо делать :)
Да я как бы не претензии высказываю, а узнать хочу :) В каких случаях вообще предпочтителен VirtualAlloc и в чем его плюсы или где про это прочитать?

вопросециспользовать из другого узла,

VirtualAllocXXX предпочтителен, когда вам нужен большой кусок памяти, но всю ее вы сразу использовать не планируете. Скажем выделили диапазон виртуальных адресов (reserve), это влияет только на AVL-дерево в узлах которого находятся VAD. Как понял у каждого процесса свой. Операция быстрая. По мере надобности, можно делать commit отдельных страниц выделенного ранее диапазона и тогда при обращении по виртуальному адресу начнет работать механизм

CR3->PageDirectoryEntry-->PageTableEntry--(тут при page fault подкачка)-->PhysicalPage->PageOffset

Грубо говоря даже после commit, как я понял память сразу не выделяется, а выделяется on demand при обработке page fault.

Приложения, например СУБД. Я оттуда и пришел. Разбираюсь с SQL Memory Manager'ом. А он весь NUMA-aware... и свое барахло пилит через Numa-функции...
Т.е. например написали свой class virtual_allocator; через VirtualAlloc, использовали его в std::vector<char, virtual_allocator> vec, и сделали vec.resize(1024*1024*1024 * 4); - т.е. 4 GB.
Затем записали в первый и последний элемент что-то: *vec.begin() = 10; *vec.rbegin() = 20;
И реально при этом выделилось только 8KB физической памяти, 4KB для первой страницы и 4KB для последней?

вопросецКогда VirtualAllocExNuma не сможет сделать reserver/commit в пределах NODE и вернет virtual range привязанный к другому узлу NUMA или ошибку?
Логично, что вернет ошибку. Т.к. даже если не хватает физической памяти на узле, то остальное просто засвопится. А уж чтоб нельзя было засвопить - это уже критическая ошибка.
А выделиться виртуальная память привязанная к двум узлам или размещенная часть на одном, а часть на другом по идее не может?

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

http://blogs.msdn.com/b/psssql/archive/2010/02/23/how-it-works-sql-server-2008-numa-and-foreign-pages.aspx
Ну это понятно, для уменьшения задержки, потоки привязываются к ядрам узла, и используют память привязанную к этому же узлу.

А какой профит думаете получить от понимания, как внутри с NUMA работает MS SQL Server? Исходный код то закрытый и его не изменишь :)