Smart ASM: Мультизадачность. Глава 8. Задачи и страничная организация памяти.

Мультизадачность.

Глава 8. Задачи и страничная организация памяти.

Мультизадачность и страничная организация памяти могут работать независимо друг от друга, но максимальный эффект от применения защищённого режима достигается именно при совмещении этих технологий; они не конфликтуют между собой и поэтому вы можете при построении операционной системы сначала отладить взаимодействие ОС со страницами, а потом переходить к работе с задачами либо наоборот.
И всё же, есть одно ограничение при использовании задач и страниц. Если граница страниц находится внутри TSS, т.е. когда TSS пересекает границу двух или более страниц, то нужно быть внимательным, потому что процессор при работе с TSS использует преобразование линейного адреса в физический один раз, когда вычисляет адрес начала TSS. Если вторая страница будет не присутствовать или отображена не на соседнюю физическую, то процессор, перейдя границу страниц, не будет вычислять физический адрес новой, а продолжит обращаться по смежному физическому адресу. В результате будут загружены не значения полей TSS, а другая информация и это приведёт либо к нарушению контекста задачи, либо, скорее всего, к исключению. Поэтому, рекомендация - размещайте TSS целиком внутри одной страницы, либо на смежных страницах.
Во избежание этой проблемы и для упрощения работы с сегментами состояния задач, возможны два варианта:

1. Для содержимого каждого TSS, кроме его дескриптора, определять отдельный сегмент данных, в котором он будет располагаться и отображать такой сегмент на смежные страницы памяти.
2. TSS всех задач, работающих в системе, размещать в одной области памяти. В наших примерах для этого определяется сегмент данных TSS_area, но он определяется размером в 4Кб и целиком занимает одну страницу, т.к. в примерах определяется не много задач и их TSS имеют минимальные размеры. Если в вашей ОС может использоваться много задач и они будут иметь достаточно большие размеры, например, хранить в себе карты ввода/вывода и прочую информацию, то определяя такой сегмент, отображайте его явно на последовательную цепочку страниц, чтобы физические адреса, на которые будет отображён этот сегмент, были последовательны и непрерывны для всего сегмента.

Применяя эти два варианта или их комбинацию, можно создать устойчивую к сбоям структуру задач. Например, можно определить в одном сегменте все системные TSS - они, как правило, не имеют карты ввода/вывода и могут быть минимального размера, в другом сегменте - все TSS драйверов, для них подразумеваются карты ввода/вывода, и, наконец, в третьем сегменте - TSS всех прикладных задач - им "не положены" карты ввода/вывода и они все имеют подобную структуру.
Говоря о сегменте для TSS, мы подразумеваем алиасный сегмент данных, отображённый на те же адреса памяти, по которым располагается TSS, определённый дескриптором TSS. Т.к. обращаться к памяти через дескриптор TSS нельзя (это системный объект), то необходимо создавать дополнительный сегмент данных - тут мы поступаем аналогично определению LDT для задач, когда таблицы LDT всех задач расположены одна за другой в одной области памяти, которую описывает один сегмент данных. На рис. 8-1 поясняется такое расположение LDT и TSS:

Рисунок 8-1. Пример размещения всех таблиц LDT и всех сегментов TSS.

До сих пор говорилось о том, что контекст задачи целиком размещается в её TSS. Это - простой вариант, но не самый эффективный. Контексты модулей FPU, MMX и XMM как правило сохраняются и загружаются целиком одной соответствующей командой и наиболее быстро это будет происходить, когда адрес начала области, предназначенной для хранения контекста какого-либо из этих модулей, будет выравнен на границу линии кэша. Линия кэша - это элемент данных минимального размера, процессор при записи в память либо чтении из неё оперирует блоками памяти в 32 байта (в Pentium 4 - 64 байта). Поэтому, выравнивая адрес начала области памяти для контекста модулей FPU, MMX и XMM на границу линии кэша (т.е. на 32 или 64 байта), вы предотвращаете лишние циклы шины, что повышает производительность всей системы.
Сегменты состояния задачи имеют минимальный размер в 104 байта, т.е. они не кратны 32 или 64 байтам, поэтому размещая контексты устройств в TSS вы должны выбирать между потерями на лишние циклы шины и экономией памяти под TSS. В таком случае лучше будет хранить контексты FPU, MMX и XMM в отдельных от TSS областях памяти - это повысит производительность, сократит размер TSS и упростит управление задачами.

Следующая глава Оглавление Вопросы? Замечания? Пишите: sasm@narod.ru