Станислав писал(а):
Я вот подумал, что система должна иметь общую таблицу всего адресного пространства и при добавлении страниц приложениям отмечать у себя их как занятые, т.е. она имеет в своём виртуальном пространстве просто карту физического пространства, и при выделении первой страницы для приложения под создания её таблицы сможет считать её физическим адресом, который сможет загрузить в CR3.
Кстати нужно тупо сделать массив свободных страниц и при использовании страницы будем уменьшать его размер, а при освобождении добавлять в массив адрес страницы и увеличивать его размер, и нам не важно в каком порядке они там расположены, больше нам от этого массива ни чего не требуется, но нам большую работу будет делать.
Да, это называется битовой картой и стеком страниц соответственно.
grindars писал(а):
Это работает ровно до тех пор, пока в игру не вступают устройства с DMA, которые работают с физическими адресами и которым нужны буфера, непрерывные в физической памяти.
Да, такие устройства могут быть. Но также есть и устройства, которые могут работать и с несмежными буферами, например, PCI IDE. Для основного пула страниц я не использую группирование по их физ. местоположению. Для выделения смежных физ. страниц мне пока достаточно небольшого пула, занимающего базовую память.
Станислав писал(а):
Я так и думал, что возникнет такой вопрос, кстати если заполнить массив с низу в верх, то впереди будут адреса верхних страниц(участков памяти по 4096 байт), и работа начнётся с ними в первую очередь, а в начале массива с нижними адресами.
Заполнять можно по-разному. Если считать, что функция SMAP возвращает области памяти в возрастающем порядке, то у меня при инициализации физ. адреса в массиве будут идти от старших к младшим. Забор страниц выполняется с конца массива, т.е. сначала будут выделяться страницы с младшими адресами. Потом конечно все перемешается.
Цитата:
Я имею в виду что на этот случай можно создать доп. функцию и она может искать нужный объём страниц перебором, главное, чтобы работала быстро первая функция как постоянно востребованная, а вторая нужна редко и в основном при загрузке системы, когда все страницы пусты и ещё не перемешаны.
Искать перебором в большом массиве слишком накладно, тем более что ты до конца перебора не можешь быть уверен, что в массиве содержится нужное количество смежных страниц. Здесь лучше использовать карту страниц или более сложную структуру, в которой группируются блоки определенных размеров. Мне смежные физ. страницы нужны только для работы с устройствами. На момент размещения ядра по своему постоянному адресу память уже виртуальная, поэтому не требует физической непрерывности.
Вход
Регистрация
FAQ
Поиск
