OSDev http://osdev.su/ |
|
Express OS http://osdev.su/viewtopic.php?f=4&t=178 |
Страница 14 из 19 |
Автор: | Himik [ 22 авг 2013, 22:39 ] |
Заголовок сообщения: | Re: Express OS |
maisvendoo писал(а): Я у себя запилил простенький менеджер кучи, пока только для ядра. Можно хоть один байт выделить, при этом информация о выделенном блоке памяти занимает 8 байт Я тоже буду делать менеджер. У меня каждая страница будет отдельным буфером кучи, чтобы карту занятости минимизировать, локализовать до пределов 2МБ. Ну ещё не знаю как получится. phantom-84 писал(а): Himik, я надеюсь, ты не хочешь сказать, что у тебя на каждый объект по 2 мега выделяется Для объектов ядра лучше всего использовать слабы. Даже в 4 кб может уместиться множество небольших объектов, например, в 4 кб помещается 128 структур размером 32 байта. Конечно по 2МБ. Но многие ядерные объекты у меня идут сплошным массивом, без использования менеджера памяти. Конечно при наличии нормального менеджера, кое-что можно будет реорганизовать. |
Автор: | maisvendoo [ 22 авг 2013, 23:25 ] |
Заголовок сообщения: | Re: Express OS |
Himik писал(а): Конечно по 2МБ В адресном пространстве архитектуры x86_64 в 16 экзобайт это сущие пустяки В плане кучи на первое время можно сделать что-то простецкое, а потом используя имеющийся интерфейс, модифицировать |
Автор: | phantom-84 [ 23 авг 2013, 08:08 ] |
Заголовок сообщения: | Re: Express OS |
Himik писал(а): Конечно по 2МБ. Но многие ядерные объекты у меня идут сплошным массивом, без использования менеджера памяти. Конечно при наличии нормального менеджера, кое-что можно будет реорганизовать. Большие страницы значительно реже будут переходить в состояние полного освобождения, чем небольшие. Т.е. при использовании больших страниц будет очень много распределенной, но неиспользуемой памяти. Или ты вообще никогда не освобождаешь память, используемую для объектов ядра?Edited. Я сразу освобождаю освободившуюся полностью страницу, если список свободных структур данного типа непустой (в этом случае страница остается принадлежащей этому списку) и нет пустых списков свободных структур других типов (в этом случае страница отдается одному из таких списков). |
Автор: | Yoda [ 23 авг 2013, 10:47 ] |
Заголовок сообщения: | Re: Express OS |
Практика показывает, что оптимальным является смешанное выделение, позволяющее выделять по требованию как большие, так и маленькие страницы. Слаб-аллокаторы с большими страницами неэффективны, всё равно будет перерасход памяти. |
Автор: | phantom-84 [ 23 авг 2013, 11:26 ] |
Заголовок сообщения: | Re: Express OS |
Yoda писал(а): Слаб-аллокаторы с большими страницами неэффективны, всё равно будет перерасход памяти. Так я об этом же. Слабы с большими страницами будут очень неэффективны. Слишком низкая вероятность задействовать однажды выделенные страницы под другие нужды. Хотя в принципе большие физические страницы можно разбивать на небольшие логические и тэгировать каждую логическую страницу. Это позволит в отдельно взятой физической странице одновременно хранить объекты разных типов. Останется только проблема освобождения слабовых страниц под нужды, не связанные со слабами.
|
Автор: | Himik [ 23 авг 2013, 12:03 ] |
Заголовок сообщения: | Re: Express OS |
Если один раз некий буфер задействован, значит он полезен для системы и желательно иметь его в постоянной готовности, особенно на случай конца свободной памяти. Я понимаю, что издержки памяти будут, но это ведь компромисс быстродействие/расход памяти. К некоторой потере памяти я был морально готов изначально. Надеюсь, что потери будут не слишком большими. Эксперимент покажет. |
Автор: | phantom-84 [ 23 авг 2013, 12:25 ] |
Заголовок сообщения: | Re: Express OS |
Himik писал(а): Если один раз некий буфер задействован, значит он полезен для системы и желательно иметь его в постоянной готовности, особенно на случай конца свободной памяти. Проблема в том, что тебе может не хватать памяти под один тип объектов, когда у другого типа объектов имеется очень много неиспользуемой памяти, а ты вынужден выделять новую страницу, хотя другому типу объектов его неиспользуемая память в таком объеме может не понадобиться "никогда". Я предложил тебе вариант решения этой проблемы (отредактировал пред. пост).
|
Автор: | Himik [ 23 авг 2013, 18:44 ] |
Заголовок сообщения: | Re: Express OS |
У меня ситуация не простая, и слабы скорей всего не понадобятся (не помогут). Вся объектная система у меня работает в пользовательском уровне, где есть стандартные Сишные средства распределения памяти. Просто во многих случаях я не использовал Сишных функций malloc или new, а делал запросы напрямую к ядру. Надо для начала редизайнить код. А в остальном запросы памяти к ядру обезличены, это простые блоки под mmap и расширение границ brk. |
Автор: | maisvendoo [ 23 авг 2013, 18:52 ] |
Заголовок сообщения: | Re: Express OS |
new это "приплюснутая" фишка уже, чисто сишная это маллок. У меня аналогично - куча ядра это костыль, рабочая надстройка над страничной моделью. Вот сейчас задумался над планированием памяти из пользовательского режима и запуске процессов и много дум по этому поводу... Сейчас у меня есть пара kmalloc/kmalloc_a (последняя для создания структур системы страничной памяти с выравниванием по 0x1000 блокам), и kfree, причем куски памяти освобожденные kfree беруться в оборот при новом выделении, как и положено. Просто в процессе разработки упершись в многозадачность и юзер мод, захотел реализовать их сначала, и системные вызовы. А теперь сталкиваюсь с упущениями в дизайне системы, когда цель достигнута |
Автор: | Himik [ 23 авг 2013, 21:53 ] |
Заголовок сообщения: | Re: Express OS |
Ммм, запамятовал что в ядре нет libc, а вместо malloc используется своя заглушка переправляющая запросы ядру. Так что менеджеру быть. |
Страница 14 из 19 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |