OSDev

Я тоже буду делать менеджер. У меня каждая страница будет отдельным буфером кучи, чтобы карту занятости минимизировать, локализовать до пределов 2МБ. Ну ещё не знаю как получится.

Конечно по 2МБ. Но многие ядерные объекты у меня идут сплошным массивом, без использования менеджера памяти. Конечно при наличии нормального менеджера, кое-что можно будет реорганизовать.

В адресном пространстве архитектуры x86_64 в 16 экзобайт это сущие пустяки
В плане кучи на первое время можно сделать что-то простецкое, а потом используя имеющийся интерфейс, модифицировать

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

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

Практика показывает, что оптимальным является смешанное выделение, позволяющее выделять по требованию как большие, так и маленькие страницы. Слаб-аллокаторы с большими страницами неэффективны, всё равно будет перерасход памяти.

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

Так я об этом же. Слабы с большими страницами будут очень неэффективны. Слишком низкая вероятность задействовать однажды выделенные страницы под другие нужды. Хотя в принципе большие физические страницы можно разбивать на небольшие логические и тэгировать каждую логическую страницу. Это позволит в отдельно взятой физической странице одновременно хранить объекты разных типов. Останется только проблема освобождения слабовых страниц под нужды, не связанные со слабами.

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

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

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

У меня ситуация не простая, и слабы скорей всего не понадобятся (не помогут). Вся объектная система у меня работает в пользовательском уровне, где есть стандартные Сишные средства распределения памяти. Просто во многих случаях я не использовал Сишных функций malloc или new, а делал запросы напрямую к ядру. Надо для начала редизайнить код. А в остальном запросы памяти к ядру обезличены, это простые блоки под mmap и расширение границ brk.

new это "приплюснутая" фишка уже, чисто сишная это маллок.
У меня аналогично - куча ядра это костыль, рабочая надстройка над страничной моделью. Вот сейчас задумался над планированием памяти из пользовательского режима и запуске процессов и много дум по этому поводу...
Сейчас у меня есть пара kmalloc/kmalloc_a (последняя для создания структур системы страничной памяти с выравниванием по 0x1000 блокам), и kfree, причем куски памяти освобожденные kfree беруться в оборот при новом выделении, как и положено.
Просто в процессе разработки упершись в многозадачность и юзер мод, захотел реализовать их сначала, и системные вызовы. А теперь сталкиваюсь с упущениями в дизайне системы, когда цель достигнута

Ммм, запамятовал что в ядре нет libc, а вместо malloc используется своя заглушка переправляющая запросы ядру. Так что менеджеру быть.