Liberatum.ru

Причина, по которой Vista казалась медленной пользователям, теперь стала очевидной разработчикам из Microsoft: эволюция компьютерного оборудования и, в частности, процессоров превошла ожидания пользователей [и самих разработчиков] на момент премьеры Vista в начале 2007 года. Но развитие виртуализации и рост популярности многоядерных решений привел к тому, что Vista должна была управлять системами, общее количество ядер в которых превышало 64.

Создатели системы попросту не ожидали, что операционной системе придется управлять большим количеством ядер так скоро. По крайней мере, так заявили разработчики на PDC 2009 в Лос-Анджелесе. Когда независимые специалисты рассуждали о падении производительности в системах с количеством ядер, превыщающем восемь, серверные администраторы уже наблюдали его. Были уступки, на которые Microsoft пошла в Windows Vista, - эдакие компромиссы, обеспечиваемые сложными методами для упрощения выполнения определенных задач.

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

Марк Руссинович, эксперт Microsoft по производительности, является одним из наиболее популярных докладчиков каждый год на PDC и это в основном потому, что с самого начала своего выступления он демонстрирует полное понимание того, о чем рассказывает. Даже такому эксперту сложно показать Vista в хорошем свете, и Руссинович, надо отдать ему должное, даже не пытался.

После опроса аудитории о том, кто из них использует Windows 7 на повседневной основе (практически все 400 человек подняли руки), Руссинович спросил их: "Кто из вас до сих пор работает с Windows Vista, потому что она такая замечательная?" Затем он сделал паузу в ожидании ответа, а когда увидел, что практически все руки опустились, сам ответил на свой вопрос: "Я так и думал".

"Одна из вещей, которые сделали в Windows 7, продиктована четким и ясным сообщением от сообщества наших пользователей, а также ростом популярности нетбуков" - продолжил он. "Люди хотели компактную, эффективную, быструю ОС с низким потреблением электроэнергии. Поэтому мы прилагали к проекту громадные усилия от начала и до самого конца, от планирования до релиза. Так что это, по сути, первый релиз Windows, который требует меньше места на диске, чем предыдущая версия Windows, и это несмотря на добавление массы новых функций".

Чтобы превозмочь негативное отношение к Vista, Windows 7 должна была обладать такой масштабируемостью, которую пользователи смогли бы видеть и оценивать ежевневно.

Инженер ядра Windows Арун Кишан (Arun Kishan) так объяснил суть проблемы: "Когда мы планировали обеспечить поддержку 256 логических процессоров, мы поставили цель добиться масштабируемости порядка 1,3 - 1,4x, при этом предварительный TPCC составлял 1.4x на 128 логических процессоров в сравнении с 64-процессорной системой. Что же, не так и плохо, но мы увидели, что около 15% процессорного времени было затрачено в ожидании спинлока (от англ. spinlock)". Здесь подразумевается способ временной изоляции потоков от выполнения фрагмента ядра, когда этот фрагмент исполняется в другом потоке. Чтобы логические процессоры не простаивали, им приходится непрерывно "вращать свои колеса" или, по сути, бежать на месте.

"Получается, что 15% потерянного времени на 128-процессорной системе означает, что больше 15 из этих процессоров постоянно находятся в ожидании спинлока. Таким образом, оборудование используется не на все 100%".

Часть старого ядра Windows, которая отвечала за планирование, была диспетчером и она была защищена глобальным замком (от англ. lock). "Замок базы диспетчера изначально защищал целостность всех связанных с планированием структур данных" - говорит Кишан. "Сюда относятся приоритеты потоков, очереди готовности, любые объекты, которые могут ждать - семафоры, мьютексы, таймеры I/O, асинхронные вызовы процедур - все они были защищены планировщиком, который защищал все замком диспетчера.

"Со временем мы переместили некоторые пути из замка диспетчера путем добавления дополнительных замков, таких как замки потоков, замки таблицы таймеров, замки контрольной блокировки и другие" - объяснил Кишан. "Однако, при этом замок диспетчера в основном использовался для синхронизации состояния потоков. Так что в случае, если поток запущен и ждет набора объектов, находясь в режиме ожидания, этот переход будет синхронизирован с замком диспетчера. Причиной, по которой необходим глобальный замок, является сама ОС, обеспечивающая приложениям широкие возможности: приложение может ждать один объект, может ждать один объект с задержкой, может ждать несколько объектов и сообщить: "Эй, я просто хочу дождаться любого из этих объектов", а может и сообщить: "Я хочу дождаться каждого из них". Можно перемешивать и сочетать типы объектов. Поэтому, чтобы обеспечить такую гибкость, необходимо было использовать глобальный замок диспетчера. Но обратной стороной такого решения стал наиболее сложный с точки зрения конкуренции замок, усложняющийся по мере увеличения количества ядер".

В новом ядре Win7 и Windows Server 2008 R2 мы полностью отказались от замка диспетчера - критический элемент архитектуры, присутствующий в Windows вплоть до Windows Vista, исчез. На замену замку диспетчера пришла более точная блокировка с одиннадцатью типами замков для нового планировщика - для потоков, процессоров, таймеров, объектов - и правилами получения замков, призванными избежать взаимоблокировок. Контроль синхронизации на глобальном уровне больше не производится, объяснил Кишан, поэтому многие операции не нуждаются в замках. А благодаря транзакционной семантике появились параллельныи пути - сложные пути для потоков и процессоров, которые их выполняют.

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

Марк Руссинович также поведал о том, что новая система предназначена для увеличения времени простоя процессоров (как логического, так и физического) с целью увеличить эффективность работы. " Коалесцирующие таймеры призваны свести к минимуму количество прерываний таймера в системе" - объяснил Руссинович. "Таким образом, процессоры дольше находятся в режиме простоя и потом могут заснуть.

Иными словами, нагрузка процессоров работой с целью снижения времени отклика - одна из методик, которая, как нам говорили, была одним из преимуществ Vista - в результате снижает общую эффективность системы. Многоядерные процессоры работают лучше, когда их логические процессоры можно отправить в режим сна (или осуществить их парковку), а их активные потоки будут переданы другому логическому процессору. Постоянная поддержка активности логических процессоров приводит к увеличению нагрузки на планировщик.

Вот еще один тезис, в логичности которого могут усомниться многие пользователи: для системы наиболее эффективно использовать максимальное количество памяти, которое только возможно, но не для заполнения ее конкретными данными, а для заполнения страниц памяти хоть чем-то. В качестве иллюстрации к своему семинару известный инженер Microsoft Лэнди Вонг (Landy Wang) показал диспетчер задач Windows 7, где на компьютере с 8 Гб системной памяти и обычными системными процессами всего 97 МБ доступной памяти.

"Многие люди могут подумать "Ого, 97 мегабайт свободной памяти - это очень немного для компьютера с таким объемом памяти" - говорит Вонг. "Для нас чем меньше свободной памяти, тем лучше, потому что пустые и обнуленные страницы никакой пользы системе не приносят. Мы предпочли бы заполнить эти страницы данными, которые могут вам понадобиться через определенное время, и тогда вам не придется ждать загрузки с медленного локального диска или удаленного сетевого. Поэтому мы, как правило, заполняем эти пустые и обнуленные страницы информацией, которой вы пользовались в прошлом, или исполняемыми файлами, которыми, как мы думаем, вы будете пользоваться в ближайшем будущем, и при запросе этой информации вам более не придется ждать. Да, вся эта информация находится в памяти, но не нужно все понимать буквально и говорить, что система потребляет слишком много памяти".

Вон выдержал паузу, а затем добавил: "Мы действительно используем много памяти, но мы искренне считаем, что используем ее грамотно".

Арун Кишан объяснил замок страницы диспетчера и отказ от его использования в Windows 7 путем замены более сложной системой символической семантики, которая позволяет выполнять потоки параллельно - более эффективным образом. Замки, которые никогда не были проблемой в эпоху Windows XP в итоге стали серьезным препятствием для Vista, и более чем в одном отношении, как Landy объяснил: "По мере нашего продвижения на все высшее и высшее число ядер, блокировка номера страницы фрейма[PFN ] была тем, что мы исторически использовали на протяжении почти 20 лет для управления массивами баз данных фреймов страниц - практически непрерывным, хотя может быть физически редким массивом ".

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

На 32-битной системе с 64 Мб памяти по 4 К на странице используется 16 миллионов страниц. Каждая база данных PFN состоит из 28 байт, входящих в состав 32-байтного сегмента, при этом общий размер базы дает нам 450 МБ виртуального адресного пространства. "Можно подумать, что это низкая плата за преимущества. Это определенно ниже 1% от объема физической памяти вашей машины,поэтому ожно подумать, что это вполне сносный результат. Но для нас этого было слишком много, потому что мы поняли, что в то время как физическая стоимость низка, виртуальная стоимость непомерно высока".

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

"Проблема с замком PFN заключается в том, что большинство всех виртуальных операций памяти были синхронизированы по одному общесистемному замку PFN" - говорит Лэнди Вонг (Landy Wang). "У нас был всего один замок, охватывающий весь этот массив, и это хорошо работало, но 20 лет назад, где четырехпроцессорными были лишь мейнфреймы, 64 МБ были неслыханной роскошью, поэтому базы PFN были довольно малы - максимум несколько тысяч записей.

Теперь же под замок PFN попадает все больше операций и структур данных - инженеры ожидали такого увеличения числа процессоров ближе к 2016 году. Это увеличило влияние на глобальные замки, и в Vista старая архитектура дала сбой. Вонг поделился интересной статистикой, которая, казалось, не удивила в зале никого - она просто подтвердила то, что они давно знали: хотя спинлок составлял около 15% процессорного времени на системах с 16 ядрами, это число стремительно увеличивалось, в частности, на SQL-серверах. "При переходе на систему с 128 процессорами SQL-сервер блокировал около 88% PFN. Он пытался блокировать одну из двух попыток, но был вынужден ждать. Это очень много и хуже всего, что со временем ситуация будет лишь ухудшаться".

Так что от этого глобального замка в Windows 7 также отказались, а ему на смену пришли более сложные и точные замки, где каждая страница получает свой собственный замок. В результате, как сообщил Вонг, 32-процессорные системы оказались в Windows Server 2008 R2 в 15 раз быстрее при выполнении операций на SQL-сервере и в иных приложениях - и это благодаря изменениям в методике блокировки, которая, ко всему прочему, совместима со старой системой. Код приложения не должен измениться.

Получилось так, что слабые места в архитектуре, концепции которой были заложены еще два десятилетия назад, стали причиной неудач Vista. В Windows 7 они были заменены более эффективной системой. Однако, ни для кого ни секрет, что мощность процессоров и виртуализация со временем будут увеличиваться. Таким образом, серьезные изменения в архитектуре Windows 7 могут оказаться, по сути, временной мерой, до того момента, когда будут предприняты еще более резкие меры.

Оценка: Select rating Бред Скучновато Нормально Интересно Гениально!

Пока без оценки