OSDev

Во, во. А самое главное зачем перезагружать сегментные регистры, если большинство из них (у меня cs, ds, es, ss) в старой и в новой задачах должно содержать одни и те же значения (переключение происходит в режиме ядра). Есть еще TR, а фактически сохранение/загрузка множества ненужных значений в/из TSS. Про такой (практически никому ненужный) реликт, как LDTR, я уже молчу.

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


Скажем так. С точки зрения влияния на общую производительность нас больше волнуют часто выполняющиеся переключения задач в нормальных условиях. Как правило, это обращение к системным функциям и обмен сообщениями между задачами. Мне кажется, здесь реально замерить накладные расходы. Если рассматривать ненормальные условия, то по большей части это page fault, что в целом тоже не очень сложно замерить. В общем, надо бует попробовать на реальном оборудовании.


Да не так уж и много там ненужных значений. Кроме сегментных регистров, это указатели стеков неиспользуемых уровней привилегий (которые, кстати, и не трогаются процессором без необходимости), это, пожалуй, только линк и LDTR.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Глубоко заблуждаетесь, и дело здесь не в оптимизации. Мог измениться сам дескриптор, а не ссылка на него, поэтому процессор просто обязан перезагрузить его, если перезагружена ссылка.

Мда, действительно. Эххблин, получается, одна архитектурная кривизна накладывается на другую, в результате в целом хорошая идея (аппаратное переключение задач) становится невостребованной. Похоже, придётся отказаться от неё. А так хотелось сделать девственно чистое адресное пространство пользовательской задачи, без кусков ОС. Было бы красиво.
Хочется крепко выругаться в адрес Intel.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Не такая это и хорошая идея, как Вам кажется. Если её реализовать, то каждый раз, когда оси потребуется обратиться в адресное пространство задачи пользователя (а такое случается весьма и весьма часто), придётся настраивать определённым образом таблицы переадресации, сбрасывать (по крайней мере, частично) TLB и всё такое прочее... В общем, и эффективность снижается, и больше геморроя при создании собственно ядра. А без этого всё просто: есть контекст собственно ядра (не привязанный ни к какой задаче) и есть контекст ядра для определённой задачи.

Yoda, ни кто не говорит, что ядро должно быть размером 1ГБ. Минимизируй, сделай 4МБ, для задачи незаметно будет.

Это в любом случае потребуется делать. Либо минимизируем адресное пространство ОС, тогда придётся динамически мапировать страницы, либо отъедаем внушительную часть адресного пространства задачи.


Естественно. Так я и планирую сделать.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

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

Это очевидно. Но монолит по ряду причин и не рассматривается. Делается микроядро.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>