OSDev

Здесь можно будет устроить небольшой FAQ по ядру операционной системы.

Управление памятью - серьёзный процесс, состоящий, в основном, из трёх ступеней:
- Распределение физической памяти (paging+swap).
- Выделение блоков фиксированной длины (обычно кратных размеру страницы).
- Выделение блоков переменной длины.
С точки зрения реализации API ядра, я считаю, достаточно реализовать первые два. Остальное (дробление блока на подблоки) можно осуществить на прикладном уровне.
В ядре же встроен свой достаточно примитивный менеджер памяти, осуществляющий выделение/освобождение блоков переменной длины в одном выделенном блоке фиксированной длины.
Принцип его основан на регистрации так называемых "дырок". Каждая "дырка" - это свободное пространство. Когда выделяется память, от минимальной "дырки" (размер которой больше или равен размеру выделяемого блока) отрезается кусочек и предоставляется системе. При освобождении этот кусочек приклеивается к соседней "дырке" (если таковая имеется) или создаётся новая "дырка". Если у "дырки" отрезали кусочек и её размер стал равен нулю, "дырка" уничтожается. Дескрипторы дырок хранятся в странице памяти. Если страницы не хватает под "дырки", выделяется ещё одна и прилинковывается к основной по принципу однонаправленного списка.

Какая интересная дырочная терминология :)
Я предпочитаю называть их свободными блоками.

ИМХО первый пунк приложениям тоже глубоко пофиг...
Приложения должны видеть (иметь возможность) только пункт 2.

Причем всетаки думаю, что будет проще иметь один менеджер памяти (либа?)
А то зоопарк менеджеров памяти и в GNU достал, там у каждого пакета на всякий случай есть свой :)

SadKo, побайтовая нарезка блока это наверно лишнее. В каждом языке программирования есть свой malloc или gc, который этим занимается. Программы обычно запрашивают большой кусок памяти целиком.

Chizh, Побайтовая нарезка используется только в ядре для своих же нужд... приложением выдаются только большие блоки. Для себя пусть приложения режут как хотят... :)

PS: Кстати побайтовая нарезка реально не имеет смысла... предпочитаю почетырехбайтовую :)

Блоков фиксированной длины достаточно при низкоуровневом программировании. При высокоуровневом программировании, когда структура памяти приложения известна лишь примерно, память распределяют именно блоками переменной длины, поэтому большинство ОС предоставляет на этот случай соответствующий сервис, чтобы каждый раз не изобретать велосипед на прикладном уровне. Хотя лично я пока не реализовал соответствующие функции в своей оси: выделение реализовано по базе, выровненной на границу страницы, и длине в байтах, преобразуемой к длине, кратной размеру страницы; высвобождение по тем же параметрам, но не обязательно с теми же самыми значениями. Короче все пока ориентировано на то, чтобы поверх имеющего сервиса организовать более универсальные функции.

Phantom-84, Мелкую нарезку не рационально перекладывать на ядро... ядру проще работать глобально... типа тебе 4 виртуальных мега и тебе 4 виртуальных мега и тебя тоже вылечат...

Но стандартный менеджер (библиотека), который будет резать блоки в мелкий фарш - очень разумный шаг...

Dron, именно это я и имел в виду. Что уровень 1 существует только в ядре, и его проблемы, как это реализовано. Уровень 2 виден приложению. Уровень 3 рационально сделать отдельной библиотекой для приложений. При чём, насколько я помню, в glibc память выделяется с адресом, кратным 8.
Что касается ядра, то ему тоже нужно выделять небольшие участки памяти под структуры. Рационально написать и свой ядерный распределитель памяти, что у меня сделано.

Для оси написанной на си это естественно - нужно организать системную "кучу", внутри которой распределять память для структур ядра. Для тех, кто пишет ядро исключительно на ассемблере, можно использовать и другой вариант - в пространстве ядра для каждого вида структур зарезервировать свой участок памяти, взяв размеры всех структур такими, чтобы группы этих структур четко укладывались в отдельные страницы, после чего для каждого вида структур организовать свою табличку страниц, где бы учитывался не только факт присутствия страниц, но, например, и количество структур, находящихся внутри отдельно взятой страницы, чтобы их можно было легко создавать и удалять внутри этой страницы. Объединение структур по видам позволяет избежать операций типа слияния нескольких небольших смежных участков памяти в один более крупный, а кроме того позволяет легко высвобождать и забирать страницы физической памяти, т.к. счетчики структур можно использовать как индикаторы для высвобождения/забора физической памяти.

В C++ такое тоже есть. В STL, например, это реализовано как Allocator<class T>.