Археологические раскопки ядра vista-longhorn

         

Менеджер памяти


Перечень изменений, затрагивающих менеджер памяти (memory manager) можно найти в мультимедийной презентации http://go.microsoft.com/fwlink/?LinkId=67468 и документе download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/kernel-en.doc.

В первую очередь следует отметить (то есть отмести) улучшенную поддержку NUMA-памяти, впервые появившуюся в Server2003 SP1 и отсутствующую в XP. Напрочь. И вовсе не из жадности (или сложности реализации), а за полной ненадобностью. Аббревиатура NUMA расшифровывается как Non-Uniform Memory Architecture (Архитектура с Неоднородной Памятью) и охватывает как многопроцессорные машины, так и целые кластеры. Системный планировщик XP ставит все потоки в очередь и гоняет их по кругу, при этом в различные моменты времени каждый поток выполняется то на одном, то на другом процессоре, что снижает производительность за счет накладных расходов на поддержку когерентности (согласованности) всех КЭШей. В Server 2003 SP1 появилось несколько новых API-функций: VirtualAllocExNuma(..., Node), MapViewOfFileExNuma(..., Node) и CreateFileMappingExNuma(..., Node), указывающих системе, что поток предпочтительнее всего запускать на том процессоре, на котором и произошло выделение памяти. Двуядерные и HT-процессоры, разделяющие общий кэш между всеми потоками, к этому абсолютно нечувствительны и выигрыш в производительности будет замечен только на двух _физических_ процессорах, конечно, при условии, что приложение использует новые вызовы API, а такие приложения появятся не скоро… Тоже самое относится и к поддержке расширения AWE, преодолевающему барьер в 4 Гбайта физической памяти на x86 системах. Это чисто серверная штучка и "бытовые" приложения не нуждаются в таких количествах оперативной памяти, во всяком случае пока…

В связи с поддержкой больших объемов памяти, Microsoft реализовала механизм динамического выделения адресного пространства (dynamic system address space). Если раньше каталог виртуальных страниц инициализировался на ранних стадиях загрузки оси, резервируя 1,5 Мбайта на x86 системах, 3 Мбайта, на x86 системах с поддержкой PAE (Page Address Extension) и 2,5 Гбайта на x86-64 и IA64, то сейчас выделение памяти и построение страничного каталога происходят по мере необходимости (on-demand), что слегка ускоряет загрузку, но ощутимо замедляет работу приложений, "пожирающих" память.
И, если на серверах, работающих на 64-битных процессорах или процессорах с поддержкой AWE, этот шаг еще хоть как-то оправдан (действительно, глупо инициализировать все адресное пространство, не будучи уверенным — понадобиться ли оно или нет), то рабочие станции однозначно оказываются в явном проигрыше.



Рисунок 2 страничный каталог (Page Table) хранит соответствие между физическими адресами (physical address) и страницами виртуальной памяти (virtual memory)

Параллельное "обнуление" (zeroing) страниц, появившееся в Server 2003 SP1, так же относится к кластерам и не дает никакого выигрыша даже на многопроцессорных системах, поскольку физическая память — одна. Или… все таки дает?! Как сказать… Физическая память страдает огромной латентностью и если "обнуляемые" страницы окажутся принадлежащими различным DRAM-банкам, мы получим практически двукратный выигрыш производительности, но здесь — все дело случая.

Поддержка новых типов проекций и, в частности, чередующихся виртуальных адресных дескрипторов — Rotate Virtual Address Descriptors (или сокращенно VADs) позволит видео-драйверам полнее использовать возможности шины AGP, быстрее отображая видеопамять на адресное пространство прикладных приложений, с выбором одного из следующих типов проекций: cached, non-cached, write-combined AGP или video-RAM mappings, что несомненно порадует геймеров, но никак не скажется на судьбе остальных пользователей.


Содержание раздела