Дедупликация страницы исполняемого кода драйверов OC Windows (1187398), страница 10
Текст из файла (страница 10)
Всего Writable страниц кода - 2%, данных - 17% отобщего числа страниц драйвера. Всего NonWritable страниц (и кода и данных) = 18106,что составляет 81% всех страниц: 57% - это код и 24% - это данные.2.4.2. Нахождение λ и сравнение результатов с математической модельюНекоторые драйверы были протестированы более подробно. Среди них какпростейшие тестовые драйверы, так и более сложные (например, http.sys).Во-первых,Былопротестированосогласованиеповедениядрайверасматематической моделью. Для этого было проведено большое количество экспериментов,в каждом из которых измерялось время до первого обращения драйвера к определеннойстранице памяти. Как уже было показано ранее, обращения драйвера к странице на записьфиксируется с помощью встройки в обработчик исключения ошибки страницыMmAccessFault.Порядок проведение эксперимента: выбиралась определенная страничка драйвера иотслеживались записи только в нее.
Драйвер запускался N раз, где N варьировалось от 100до 10 000. При каждом запуске измерялось- время до Page Fault, то есть время допервого обращения в страницу на запись.После сбора данных, во-первых, строилась статистическая функция распределения,а во-вторых, раcсчитывалась интенсивность Пуассоновского потока в математическоймодели ƛ .Поскольку математическое ожидание T = 1/ƛ , то ƛ рассчитывалось какобратная величина от T – среднего значения измеренных величинзаписивПослеэтогостроилисьисравнивались– время до первойстраницу.графикидлятеоретическойиэкспериментальной (статистической) функции распределения.Статистическая функция распределения оказалась не непрерывной, а дискретной.По результатам 10 000 экспериментов для одной из страниц, величина t – время до первойзаписи на страницу, принимала лишь 11 различных значений.59Были получены результаты для всех NonPageable страниц драйвера http.sys, вкоторые он выполняет запись, даже для страниц данных.
Однако, здесь приводится лишьодин график, так как графики статистических функций распределения и полученные дляразных страниц ƛ оказались очень похожими.Экспериментальные данные приведены в таблице и на графике:Значениевремени153146627893109125140156281Какчастовстречается2209558140715531500124512112971631Таблица3.60График 1 – сравнение функций распределения. Ряд 1 – экспериментальные данные,Ряд 2 – теоретическая функция распределения с интенсивностью ƛ , полученной изэксперимента.На графике 2 показан графический расчет ƛ . В данном эксперименте параметр ƛрасчитывался двумя способами, как 1/T, т из графика. Посколькупостроив зависимостьтоот t, где p – доля от общего количества значенийвремени, соответствующая этому t, мы получим прямую, проходящую через ноль, иимеющую угол наклона ƛ .График 2. Графический расчет ƛ .Как видно из графиков, экспериментальные данные довольно хорошо согласуютсяс математической моделью, а значит, можно сделать вывод, что поведение драйверов вцелом хорошо согласуется с моделью Пуассоновского процесса.Кроме того, были протестированы различные драйверы, они так же показалихорошее согласование с математической моделью, а ƛ для них оказалась в пределах [0,0.8].Кроме этого, в процессе эксперимента было установлено, что процент доступныхдля записи (writable) страниц, в которые действительно велась запись оказался впромежутке [0, 60%] для различных драйверов.612.4.3.
Время загрузки драйвераВ работе так же считались накладные расходы. В данном случае, поскольку цельработы – оптимизация работы с памятью, наблюдается незначительное снижениепроизводительности, а именно немного увеличивается время загрузки драйвера в систему.Были произведены измерения времени работы системы, времени обработкиисключения ошибки страницы Page Fault, дополнительного времени, которое теперьтратится на загрузку одного из драйверов, будь то первый экземпляр, или последующие, атак же выявлены этапы работы, которые вносят наибольшую задержку.Для тестирования использовался драйвер http.sys, так как это драйвер снаибольшим количеством страниц в системе, а значит, и время загрузки у негомаксимальное.Был произведен ряд экспериментов, по результатам которых получилось:Время, на которое увеличивается время загрузки первого экземпляра ~ 40 ms.Время, на которое увеличивается время загрузки второго и последующихэкземпляров ~ 5 ms.Время обработки Page Fault ~ 15s.Таким образом получается, что если в контейнере 100 драйверов, то время стартапервого контейнера увеличивается на ~ 2-3 сек (потому, что большая часть драйверовгораздо меньше, чем http.sys).
А время старта второго и последующих контейнеровувеличивается меньше, чем на секунду! Причем, это время можно еще уменьшить, потомучто основную задержку дает выделение и высвобождение страниц, а высвобождениестраниц можно сделать отложенным, что сэкономит еще 5-10 ms.2.4.4. Тестирование Pageable страниц.В работе не строится математическая модель подкачки страниц, однако, дляподсчета выигрыша необходимо знать количество Pageable страниц, которые были впамяти до начала работы.Был произведен ряд тестов, в которых для разных драйверов считалось количествоподкачиваемых страниц, находящихся в памяти.
Приведем тут значения для драйвераhttp.sys. Всего у этого драйвера 44 Pageable страницы, из них в определенный момент в62памяти находилось 15, в то время как 29 были сброщены на диск. Естественно, этипараметры меняются во время работы системы. А так же, они очень зависят от типасамого драйвера.
Однако, общее правило для драйваеров на моем компюьтере былотаким:60% - откачено на диск40% - находится в памяти.2.4.5. Подсчет выигрышей.Для того, чтобы подсчитать выигрыш, необходимо знать количество страницдрайвера, относящихся к разным типам.Приведем эти данные для драйвера http.sys.ТипcnprСтрани 45цыcnpwcprcpwdnprdnpwdprdpw8440401300Таблица 4.Всего в драйвере 150 страниц, каждая страница – 4 Кб, следовательно всего 600 Кбпамяти.Расчет для случая неподкачиваемой памяти: NP, r = 45 *4 = 180 Кб; NP,w = (8-3) *4= 20 Кб (Так как в резервном буфере было по 3 страницы для каждого драйвера).Расчет для случая подкачиваемой памяти: P, w = 0.Для P, r: Всего 44 страницы, из них 15 было в памяти для каждого драйверараньше, а теперь для всех драйверов будет ровно 44 страницы.
Тогда выигрыш будет(15*N - 44) * 4 Кб, то есть это выгодно, когда N>3.Пусть N = 10. Тогда выигрыш: 200 б (от NP) * 9 + (15*10 - 44) * 4 б (от P) = 1800 +424 Кб = 2224 Кб = 2,2 Мб. А всего, без нашей системы было бы 5б8 Мб. Получаемэкономию: 38% .Пусть N = 100. Тогда 200*99 + (15*100 - 44)*4 = 19 800 + 5 824 = 25 624 б = 25,0Мб.А всего было бы 58.6 Мб. Экономия: 43%.63Таким образом в зависимости, от количества драйверов в системе можно получитьэкономию памяти порядка 50% ! А выигрыш исчисляется десятками мегабайт.Все выше сказанное доказывает эффективность и необходимость созданнойсистемы.643. Заключение3.1.
РезультатыДанный алгоритм реализован для случая NonPaged Memory.В процессе работы над реализацией драйвера, дедуплицирующего код другихдрайверов, был разработан и реализован ранее отсутствовавший в Windows механизмCopy On Write в NonPaged Memory. Данный механизм реализован и для случая работыпри низких, и при высоких IRQL.
Однако, следует заметить, что для случая работы навысоких IRQL с Writable страницами при активных попытках дедуплицируемого драйвераписать в свои страница кода этот механизм не может гарантировать стопроцентнуюбезопасность и работоспособность системы. Вследствие чего, все драйверы должныпредварительно тестироваться на наличие таких ситуаций, несмотря даже на то, что онипредельно редки.Кроме этого, была детально изучена работа менеджера памяти в ОС Windows снеподкачиваемым пулом памяти. При работе над реализацией алгоритма были с самогоначала учтены особенности работы его структур, и при выборе способов реализацииучитывались в том числе и будущие затраты, необходимые для переноса даннойреализации на следующие выпуски ОС Windows.Была разработана математическая модель, достаточно полно описывающаяповедение системы и хорошо предсказывающая кол-во сэкономленных страниц.
А так жематематическая модель разделения страниц общего набора при попытках записи в нихразличными экземплярами драйвера, по которой можно определить размер заранееподготовленного буфера страниц, используемого в высоких IRQL, и кроме тогоопределить математическое ожидание кол-ва разъединенных страниц в определенныймомент времени.Был выполнен ряд тестов системы на различных драйверах, результатыподставлены в математическую модель, проверено их соответствие.653.2. Перспективы развитияРеализовать этот же алгоритм и для Paged Memory.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
