последствия ядерной войны

КРИС КАСПЕРСКИ АКА МЫЩЪХ

Спецвыпуск: Хакер, номер #072, стр. 072-062-1

NO-EMAIL

БЕЗОПАСНОСТЬ VISTA KERNEL

ЯДРО ВИСТЫ ПРЕТЕРПЕЛО МНОЖЕСТВО ИЗМЕНЕНИЙ: УСИЛИЛАСЬ (НЕ)БЕЗОПАСНОСТЬ, ДОБАВИЛИСЬ НОВЫЕ ДЫРЫ, ОПТИМИЗАЦИЯ ДОСТИГЛА ТАКОГО ПРЕДЕЛА, ЧТО ЗАТОРМОЗИЛА ДАЖЕ ДВУЯДЕРНЫЕ ПРОЦЕССОРЫ... ВООРУЖИВШИСЬ ШАГАЮЩИМ ЭКСКАВАТОРОМ, РАСКОРЫВЫРЯЕМ ЯДРО И ПОСМОТРИМ, КАКИЕ РЕАЛЬНЫЕ ПЕРЕМЕНЫ ПРОИЗОШЛИ СО ВРЕМЕН XP И СТОИТ ЛИ ЭТОТ ПРОГРЕСС ТОГО, ЧТОБЫ ЗА НЕГО ПЛАТИТЬ

[почему ядро.]

Ядро надежно скрыто от пользователя множеством слоев абстракции, но именно оно (а вовсе не «прелести» интерфейса) в наибольшей степени ответственно за «характер» операционной системы. Именно ядро управляет памятью, процессорами, вводом/выводом, разграничивает доступ к объектам и делает массу других полезных (и не очень) вещей, эффективность которых определяет надежность, защищенность и производительность всей системы в целом. На плохом фундаменте хорошего сооружения не построишь... Но если качество сооружения легко оценить невооруженным глазом, то дефекты фундамента дают о себе знать в самый неподходящий момент.

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

[производительность.]

Ядро Висты существенно «оптимизировано» (о чем свидетельствуют многочисленные тесты, предоставленные как самой Microsoft, так и независимыми исследователями), но далеко не все изменения полезны для рабочих станций и на однопроцессорных машинах с малым количеством оперативной памяти. Порой они (изменения), наоборот, вызывают дополнительные тормоза, значительно проигрывая w2k и XP в производительности, что делает ситуацию неоднозначной.

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

[менеджер памяти.]

Перечень изменений, затрагивающих менеджер памяти (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-памяти, впервые появившуюся в Server 2003 SP1 и отсутствующую в XP. Напрочь. И вовсе не из жадности (или сложности реализации), а за полной ненадобностью. Аббревиатура NUMA расшифровывается как Non-Uniform Memory Architecture (архитектура с неоднородной памятью) и охватывает как многопроцессорные машины, так и целые кластеры. Системный планировщик XP ставит все потоки в очередь и гоняет их по кругу, при этом в различные моменты времени каждый поток выполняется то на одном, то на другом процессоре, что снижает производительность за счет накладных расходов на поддержку когерентности (согласованности) всех кэшей.

В Server 2003 SP1 появилось несколько новых API-функций: VirtualAllocExNuma(..., Node), MapViewOfFileExNuma(..., Node) и CreateFileMappingExNuma(..., Node), указывающих системе, что поток предпочтительнее всего запускать на том процессоре, на котором и произошло выделение памяти. Двуядерные и HT-процессоры, разделяющие общий кэш между всеми потоками, к этому абсолютно нечувствительны, и выигрыш в производительности будет замечен только на двух физических процессорах. И то при условии, что приложение использует новые вызовы API, а такие приложения появятся не скоро. То же самое относится и к поддержке расширения AWE, преодолевающего барьер в 4 Гбайта физической памяти на x86-системах. Это чисто серверная штучка, и «бытовые» приложения не нуждаются в таких количествах оперативной памяти, во всяком случае, пока.