В случае ядра у меня, например, direct mapping, первые 768МБ я как есть мапплю в higher half, а остальное(особенно в userspace)? Искать первую свободную страницу? Кажется, это не самый производительный вариант
Я не понял как связан маппинг и свободная страница. Ты должен аллоцироовать физпамять для виртуальной, а не наоборот.
Ну аллоцировать-то я смог, у меня есть физический аллокатор, но далее мне ее нужно замаппить на какой-то виртуальный адрес и тут возникает вопрос: «на какой?»
Я тут под страницей имел в виду первый адрес в page table’е, где не проставлен бит present
не так, ты запрашиваешь маппинг для виртуального адреса X, физиеский аллокатор тебе аллоцирует страницу натурально, виртуальный адрес у тебя X
Для этого тоже нужно что-то вроде аллокатора
А что делать со служебными страницами? не всегда же можно взять и сразу замапить страницу в таблице страниц, иногда и саму таблицу страниц нужно мапить
В память процесса? Зачем.
зачем тебе мапить единичную страницу? это задача такая? Обычно мапят регионами
Да, видимо, в контексте процессов ни к чему. Хотя в контексте ядра, кажется, что имеет смысл, но там, я так понимаю, можно сразу всю память замаппить
В контексте ядра имеет смысл да. Как в офтопике с highnem
Я бы пока не думал о процессах
И как ты собрался рулить регионами физической памяти?
речь о регионах адресного пространства. Здесь нет нужды выделять непрерывную область физ. памяти
Но всё же мапить по одной странице, если речь идёт о памяти ядра, а не процесса, не лучшая идея
Ты так или иначе мапишь их по одной странице, остальное частные оптимизации
Но каждый раз бегать за страницей не есть хорошо
когда заработает маппинг поштучно оптимизация для рейнджей страниц уже тривиальна
Так ведь выбор особо не велик, если процесс замапил регион, если ты сразу все не мапишь (lazy аллокации, что обычно и делают), то пока аксесса на эту страницу не будет её и не нужно аллоцировать, только, если нет какого-нибудь алгоритма, типа fault-around
Для начала, надо с памятью ядра разобраться
Так там ещё проще, ты просто сразу аллоцируешь и мапишь
Если есть аллокатор физ. страниц и условно функция, которая мапит одну страницу, ты просто цикл вставляешь, который пройдется по региону, если это больше, чем одна страница, и замапит их все
Не всё так просто, ибо таблица страниц многоуровневая, для промежуточных уровней надо тоже откуда-то мапить, либо заранее рассчитывать сколько понадобится памяти
Все конечно зависит от того, как ты сделаешь, но не вижу проблемы, чтобы тем же аллокатором физ. страниц достать страницу для таблицы, если её не оказалось и воткнуть в уже существующую, тем более, что это ядерная таблица
Тут очень большая проблема в том, что физ аллокатор должен где-то хранить всё своё добро, т.е. списки свободных регионов, если хранить в памяти ядра, то это потенциально может вызвать рекурсивные вызовы аллокатора, что нежелательно
Ну самый простой способ - в компайл тайме указать максимальный объем памяти, который может присутствовать в системе
У меня на каждый физический регион есть битмап, правда у меня 32-бит, поэтому битман не очень большой
Обсуждают сегодня