OSDev

Поиск решения без предварительного резервирования памяти привел меня вот к какому варианту:

Возможно, кому-то пригодится хотя бы идеей.

Это вам надо учиться писать. А то вас так и не смогут понять если вы дальше будете использовать прилагательные вместо существительных.

По поводу навязывания ни в коем случае:
1. Вы сами спросили совета вам ответили. Так что нечего расстраиваться если ваше мнение не совпало с мнением других. Иначе какой смысл спрашивать?
2. Вы вольны делать как вам нравится. Я же вас не пытаю. ДА и стимула у меня нет, чтобы вас про стимулировать. Стимул - это такая палка в древнем Риме для принуждения рабов к действию.
3. Более того я сказал что это абстрактное описание, так что реализация тоже за вами.

Я прекрасно понимаю что на Осдеве собрались альтернативщики. Те кто хочет творить и создавать новое, а не следовать канонам.

Но то что я описал это наиболее оптимальный способ. Выработанный методом проб и ошибок. Просто вчера времени не хватило расписать почему именно были выбраны те или другие решения.

Сам я скорее скептик нежели чем альтернотивщик. А также приверженец ТРИЗ. А первым пунктом при решение изобретательских задач является сбор информации по существующим аналогам. А дальше уже можно пробовать изобретать: заменять одни вещи/методы другими (изменять), добавлять что-то новое или убирать лишнее(совершенствовать) или пробовать кардинально противоположный подход(ставить всё с ног на голову).

Нужна помощь в понимании написанного мной? Могу помочь, если укажете конкретное место.

И это не навязывание? Ну-ну.

Видимо, наиболее оптимальный из рассмотренных? Какие в таком случае были рассмотрены?

P.S. Для меня дико слышать замечания типа "научись писать" от неграмотного человека.

pavia и Actium,
завязываем с взаимными переходами на личности и оффтопиком.

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

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

И что за сарказм был по поводу рекурсивного отображения каталога? Если вы высмеиваете один из самых эффективных способов управления ВАП, это вас характеризует не с лучшей стороны.

Размер участка под стек страниц можно определять динамически в зависимости от реального объема физ. памяти в системе и от того, сколько физической памяти забирается из пула безвозвратно на этапе начальной инициализации.

Решение того, какую часть стека держать в ВАПе, оставлено за рамками примера. Мне хотелось передать саму идею, а не конкретную реализацию.
Я не вижу причин, почему стек должен перестать работать (ну, или работать хуже) при фрагментации физ.памяти.
Для меня очевидно, что сарказм был обоснован, разве нет?

Edit: Сейчас у меня в тестировании код, который очень похож на приведенный выше. Модель виртуальной памяти содержит участок (8 MB), зарезервированный под стек. Функции allocate_page() и deallocate_page() управляют этим участком.
Да, я прогнал несколько тестов для случая, когда в виртуальной памяти находится лишь страница с верхушкой стека. Падение производительности в среднем меньше 1%. Так что вариант с сервисной страницей совсем даже не плох (правда, не знаю, можно ли этот случай обобщать).

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

Я не увидел структуры размещения стека в несмежных физ. страницах, хотя вы даже успели упомянуть переменные под основные указатели/счетчики. Когда стек свободных страниц отображается в ВАП целиком, объединяющей структурой выступает непосредственно таблица страниц, а что выполняет эту роль при вашем подходе, непонятно.

Потрудитесь объяснить, чтобы и для меня стало очевидно. По-моему упомянутый подход хорош по всем статьям, в том числе и по экономии (хотя экономия конечно минимальная).

Да не вопрос Использование рекурсивного отображения в режиме PAE приводит к потерям примерно 1 GB виртуальной памяти. Возможно, в long mode тоже не все хорошо, я не считал.

Стек размещается в доступных фрэймах. Где именно в памяти они располагаются, неизвестно (да и не важно, я думаю). За размещение в виртуальной памяти отвечают allocate_page/deallocate_page.

Edit: Сейчас подумал, что на потери в long mode можно забить - там виртуальной памяти столько, что любые потери - мелочь

+Edit: Не представляю, зачем мне городить второе дно стеку, а занятые им фрэймы и так отдаются по мере освобождения.

Гы Это как? Размер таблицы страниц в режиме PAE – 8 мег.