UEFI-диагностика: проблемы и решения

17 Окт 2013

UEFI-диагностика: проблемы и решения

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

Из множества альтернатив лучшим вариантом представля­ет­ся UEFI, ведь к моменту старта UEFI-приложения, BIOS инициализирует контекст, обеспечивающий 64-битную ад­ресацию и беспрепятственный доступ к системным ре­сур­сам. А набор сервисных функций или UEFI-протоколов, об­рабатываемых firmware, дает в рас­по­ря­же­ние про­грам­мис­та уникальный набор возможностей, недо­ступ­ный в любой другой среде, использующей Legacy Boot.

 

Технологии новые, проблемы старые:
куда девается видео память?

Что нового можно узнать об архитектуре современных компьютеров, вооружившись UEFI-диагностикой?

Рассмотрим этот вопрос с точки зрения утилиты UEFImark, предназначенной для оценки производительности видео карты и определения процессорных параметров персональной платформы.

Результат работы программы UEFImark v0.96
Рис 1Результат работы программы UEFImark v0.96 на платформе ASUS Z87-K

Утилита UEFImark v0.96 выводит системную информацию о центральном процессоре,
видео адаптере и его режиме, размере системной памяти и видео памяти,
производительности видео памяти для различных методов записи

В предлагаемом эксперименте используется видео адаптер, оснащенный 512 Мегабайт видео памяти. Согласно строке 9 системной информации (рис. 1) объем видео памяти 256 Мегабайт или более. Почему не удалось точно детектировать объем?

Детально проанализировав системный контекст, являющийся результатом инициализации оборудования, выполненной firmware, делаем вывод: стремление обеспечить совместимость с 32-битными ОС, заставляет разработчиков платформы жертвовать оптимальностью. В чем конкретно это выражается?

Обратимся к Рис.1. Восьмая строка системной информации сообщает, что процессор использует 39-битный физический адрес. Следовательно, размер адресного пространства равен «два в 39-й степени» байт или 512 ГБ. Тем не менее, диапазон доступа к видео памяти размещен в пределах нижних четырех гигабайт, чтобы старое программное обеспечение, использующее 32-битную адресацию, могло получить к нему доступ. «Притесненный» видео адаптер, декларирует размер диапазона доступа к видео памяти всего 256 Мегабайт. Конечно, это не значит, что оставшийся объем видео памяти пропадает. Он доступен для графического процессора, а с помощью драйверов, – и для центрального процессора.

Можно сделать вывод, что конфигурация не оптимальна: при наличии 512 ГБ адресного пространства для доступа к видео памяти нельзя выделить более 256 МБ. Именно поэтому, программное обеспечение, использующее стандартные PCI PnP-механизмы, которому недоступны device-specific методы работы с графическим процессором, сможет детектировать в нашем примере только половину видео памяти.

Измерение скорости записи в видео память.
Почему так медленно?

Согласно нижней строке системной информации (рис. 1), скорость записи в видео память со стороны центрального процессора, при использовании 128-битных SSE-инструкций, равна 297.5 МБ/сек.

Вспомним, что даже для первого поколения шины PCI Express, пропускная способность равна около 4 ГБ/сек в режиме дуплекс (при параметрах соединения Width=x16, Speed=2.5GT/S). За счет чего образовался разрыв между теорией и практикой? Исследования показывают, что и в этом случае виноват неоптимальный контекст PCI PnP, установленный при старте платформы процедурами firmware.

Общеизвестно, что типовой видео адаптер использует два типа диапазонов доступа к адресному пространству памяти:

  • Non-prefetchable

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

  • Prefetchable

Диапазон с таким статусом используется для адресации видео памяти. Для нее разрешено спекулятивное выполнение, в частности Write Combining – сборка нескольких циклов записи малой разрядности в один цикл большей разрядности или пакет данных для отправки по шине PCI Express. Очевидно, такой режим существенно повышает производительность.

Но вернемся к проблеме низкой скорости записи в видео память. Она связана с тем, что firmware платформы при инициализации моста PCI Express, обеспечивающего подключение видео адаптера, размещает диапазон доступа к видео памяти в Non-prefetchable диапазоне адресного пространства, делая оптимизацию доступа к видео памяти невозможной.

Резюме

Исследования показали, что при написании firmware персональных платформ, в частности процедур инициализации и распределения системных ресурсов (PCI PnP), производительность часто приносится в жертву совместимости. Что в сложившейся ситуации могут сделать разработчики информационно-диагностических утилит для максимального раскрытия потенциала 64-битного «железа»? Ответ очевиден – вместо использования контекста, созданного firmware, создавать свой контекст, в частности, повторно выполнить процедуру распределения системных ресурсов.

В ближайшее время лаборатория IC Book Labs подготовит экспериментальный продукт под названием UEFImark Extreme Edition, реализующий именно такой подход.

Эксперименты проводились на платформе ASUS Z87-K, построенной на основе системной логики Intel Z87 для процессоров Socket 1150. Процессор Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz. Видео адаптер Sapphire X1950PRO (ATI/AMD).