OSDev http://osdev.su/ |
|
Управление физической памятью http://osdev.su/viewtopic.php?f=5&t=1048 |
Страница 7 из 10 |
Автор: | Actium [ 18 фев 2015, 11:32 ] |
Заголовок сообщения: | Re: Управление физической памятью |
Поиск решения без предварительного резервирования памяти привел меня вот к какому варианту: Код: namespace { size_t frame_count = 0; u32_t* stack; } u32_t allocate_frame() { if (frame_count == 0) throw out_of_memory_exception(); --frame_count; --stack; if (u32_t(stack) & (PAGE_SIZE - 1)) return *stack; void* page = stack; stack = reinterpret_cast<u32_t*>(*stack); u32_t frame = unmap_page(page); deallocate_page(page); return frame; } void deallocate_frame(u32_t frame) { if (frame_count == 0 || (u32_t(stack) & (PAGE_SIZE - 1)) == 0) { u32_t* page = static_cast<u32_t*>(allocate_page()); map_page(page, frame); *page++ = u32_t(stack); stack = page; } else *stack++ = frame; ++frame_count; } Возможно, кому-то пригодится хотя бы идеей. |
Автор: | pavia [ 18 фев 2015, 11:45 ] |
Заголовок сообщения: | Re: Управление физической памятью |
Это вам надо учиться писать. А то вас так и не смогут понять если вы дальше будете использовать прилагательные вместо существительных. По поводу навязывания ни в коем случае: 1. Вы сами спросили совета вам ответили. Так что нечего расстраиваться если ваше мнение не совпало с мнением других. Иначе какой смысл спрашивать? 2. Вы вольны делать как вам нравится. Я же вас не пытаю. ДА и стимула у меня нет, чтобы вас про стимулировать. Стимул - это такая палка в древнем Риме для принуждения рабов к действию. 3. Более того я сказал что это абстрактное описание, так что реализация тоже за вами. Я прекрасно понимаю что на Осдеве собрались альтернативщики. Те кто хочет творить и создавать новое, а не следовать канонам. Но то что я описал это наиболее оптимальный способ. Выработанный методом проб и ошибок. Просто вчера времени не хватило расписать почему именно были выбраны те или другие решения. Сам я скорее скептик нежели чем альтернотивщик. А также приверженец ТРИЗ. А первым пунктом при решение изобретательских задач является сбор информации по существующим аналогам. А дальше уже можно пробовать изобретать: заменять одни вещи/методы другими (изменять), добавлять что-то новое или убирать лишнее(совершенствовать) или пробовать кардинально противоположный подход(ставить всё с ног на голову). |
Автор: | Actium [ 18 фев 2015, 12:33 ] |
Заголовок сообщения: | Re: Управление физической памятью |
Нужна помощь в понимании написанного мной? Могу помочь, если укажете конкретное место. pavia писал(а): Это две структуры... И это не навязывание? Ну-ну.Когда будешь делать функции для работы с этими структурами... pavia писал(а): Но то что я описал это наиболее оптимальный способ. Видимо, наиболее оптимальный из рассмотренных? Какие в таком случае были рассмотрены?P.S. Для меня дико слышать замечания типа "научись писать" от неграмотного человека. |
Автор: | Yoda [ 18 фев 2015, 13:34 ] |
Заголовок сообщения: | Re: Управление физической памятью |
pavia и Actium, завязываем с взаимными переходами на личности и оффтопиком. |
Автор: | phantom-84 [ 18 фев 2015, 18:29 ] |
Заголовок сообщения: | Re: Управление физической памятью |
Actium, опять в ВАП только вершина стека. Ну, вы экономный! Как я понял, по поводу возможной физической фрагментации стека страниц мысли вас не посещали. Полного переотображения страницы, в которой находится вершина стека, не заметил (может, плохо смотрел?). И что за сарказм был по поводу рекурсивного отображения каталога? Если вы высмеиваете один из самых эффективных способов управления ВАП, это вас характеризует не с лучшей стороны. |
Автор: | phantom-84 [ 18 фев 2015, 18:39 ] |
Заголовок сообщения: | Re: Управление физической памятью |
Размер участка под стек страниц можно определять динамически в зависимости от реального объема физ. памяти в системе и от того, сколько физической памяти забирается из пула безвозвратно на этапе начальной инициализации. |
Автор: | Actium [ 18 фев 2015, 22:11 ] |
Заголовок сообщения: | Re: Управление физической памятью |
phantom-84 писал(а): Actium, опять в ВАП только вершина стека. Ну, вы экономный! Решение того, какую часть стека держать в ВАПе, оставлено за рамками примера. Мне хотелось передать саму идею, а не конкретную реализацию.phantom-84 писал(а): Как я понял, по поводу возможной физической фрагментации стека страниц мысли вас не посещали. Я не вижу причин, почему стек должен перестать работать (ну, или работать хуже) при фрагментации физ.памяти.phantom-84 писал(а): И что за сарказм был по поводу рекурсивного отображения каталога? Если вы высмеиваете один из самых эффективных способов управления ВАП, это вас характеризует не с лучшей стороны. Для меня очевидно, что сарказм был обоснован, разве нет?Edit: Сейчас у меня в тестировании код, который очень похож на приведенный выше. Модель виртуальной памяти содержит участок (8 MB), зарезервированный под стек. Функции allocate_page() и deallocate_page() управляют этим участком. Да, я прогнал несколько тестов для случая, когда в виртуальной памяти находится лишь страница с верхушкой стека. Падение производительности в среднем меньше 1%. Так что вариант с сервисной страницей совсем даже не плох (правда, не знаю, можно ли этот случай обобщать). |
Автор: | phantom-84 [ 18 фев 2015, 22:55 ] |
Заголовок сообщения: | Re: Управление физической памятью |
Actium писал(а): Решение того, какую часть стека держать в ВАПе, оставлено за рамками примера. Мне хотелось передать саму идею, а не конкретную реализацию. Так идея примитивна. А с полностью отображенным стеком примитивна до неприличия. У меня два основных усложнения: двойное дно, одно из которых плавающее, и выделение страниц, занятых самим стеком, когда он полностью опустошается.Цитата: Я не вижу причин, почему стек должен перестать работать (ну, или работать хуже) при фрагментации физ.памяти. Я не увидел структуры размещения стека в несмежных физ. страницах, хотя вы даже успели упомянуть переменные под основные указатели/счетчики. Когда стек свободных страниц отображается в ВАП целиком, объединяющей структурой выступает непосредственно таблица страниц, а что выполняет эту роль при вашем подходе, непонятно.Цитата: Для меня очевидно, что сарказм был обоснован, разве нет? Потрудитесь объяснить, чтобы и для меня стало очевидно. По-моему упомянутый подход хорош по всем статьям, в том числе и по экономии (хотя экономия конечно минимальная).
|
Автор: | Actium [ 18 фев 2015, 23:09 ] |
Заголовок сообщения: | Re: Управление физической памятью |
Да не вопрос Использование рекурсивного отображения в режиме PAE приводит к потерям примерно 1 GB виртуальной памяти. Возможно, в long mode тоже не все хорошо, я не считал. Стек размещается в доступных фрэймах. Где именно в памяти они располагаются, неизвестно (да и не важно, я думаю). За размещение в виртуальной памяти отвечают allocate_page/deallocate_page. Edit: Сейчас подумал, что на потери в long mode можно забить - там виртуальной памяти столько, что любые потери - мелочь +Edit: Не представляю, зачем мне городить второе дно стеку, а занятые им фрэймы и так отдаются по мере освобождения. |
Автор: | phantom-84 [ 18 фев 2015, 23:26 ] |
Заголовок сообщения: | Re: Управление физической памятью |
Actium писал(а): Да не вопрос Использование рекурсивного отображения в режиме PAE приводит к потерям примерно 1 GB виртуальной памяти. Гы Это как? Размер таблицы страниц в режиме PAE – 8 мег.
|
Страница 7 из 10 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |