FreeProger писал(а):
А что имеется в виду под памятью ядра?
Память, используемая ядром формально для своих личных целей -- в отличие от памяти, выделяемой процессам явным образом.
Проблема в том, что на многие "чихи" задач пользовательского режима ядро должно выделять память для собственных структур данных. Скажем, задача запускает новый поток -- нужно создать блок управления потоком. Задача запрашивает операцию ввода-вывода -- нужно создать блок запроса ввода-вывода. Задача создаёт семафор, таймер, мьютекс и т.д. -- ядро должно создать соответствующую внутриядерную структуру. Соответственно, память ядра постоянно расходуется на нужды задач, и, если задачи не ограничивать, может получиться так, что некая задача выжрет таким путём всю память ядра и тем самым блокирует работы системы в целом.
Кроме того, не смешивайте виртуальную и реальную память. Вся память процессов, вообще говоря, является виртуальной, и в каждый момент времени в реальном ОЗУ может находиться лишь малая её часть. Однако память ядра в идеале должна всегда лежать в реальной памяти. Поэтому память каждого процесса может быть достаточно "резиновой" и в 32-разрядном режиме ограничивается, по сути, лишь разрядностью виртуального адреса, в то время как память ядра ограничивается и разрядностью адреса, и фактически доступным объёмом ОЗУ с учётом того, что часть ОЗУ отожрана BIOSом, а какая-то часть должна быть оставлена для пользователя, причём, если физической памяти для процессов не хватает, часть страниц можно выгрузить в файл подкачки, а вот если памяти не хватает ядру, всё намного хуже (в общем случае система зависнет или упадёт -- ну или прибьёт какую-нибудь задачу в надежде освободить достаточно своей памяти).
FreeProger писал(а):
Например в KolibriOS на сколько я понял пространство делится на две части, нижние 2ГБ отводятся под процессы а верхние 2ГБ под ядро. Выходит что процесс не может занять больше 2ГБ? Но и ядру 2ГБ как то много. И из них тоже можно выделить память процессу? Просто например установлена квота в 100МБ, это значит процесс не может занять в ОЗУ больше 100МБ или это максимум что можно выделить из верхних 2ГБ для процесса?
Ну, Винде 2 гига ядру скорей мало, чем много
Но это уже к вопросу правильного проектирования и реализации системы.Кстати говоря, это деление адресного пространства поровну Колибри, надо полагать, скоммуниздила из Винды; Винда это позаимствовала из VAX/VMS (главный архитектор Винды НТ был главным разработчиком означенной системы и, естественно, использовал свой предыдущий опыт), а вот в VAX/VMS такое деление диктовалось особенностями архитектуры железа. Т.е. если в VAX/VMS такое решение было вынужденным, то повторять его в Винде не требовалось, просто об этом не задумывались, когда её создавали (4 гига ОЗУ казалось фантастикой). Собственно, в более поздних версиях Винды (по крайней мере, начиная с XP) оно и не обязательно: 32-разрядную систему можно запустить в режиме, когда ядру останется 1 гиг, а процессам будет выделяться 3 гига.
FreeProger писал(а):
Этим и занимается функция brk() в UNIX системах?
Понятия не имею, Унихи никогда меня не интересовали (точней, интересовали, но ровно до того момента, когда я не понял, что они примитивнее даже более ранних систем).
FreeProger писал(а):
И еще больше практический вопрос...
Всё ли я правильно представляю?
Всё ли я правильно представляю?
Вроде бы да.
На самом деле, размещать ядро, начиная его непременно с 80000000, не требуется. Можно, например, запихнуть его в самые верхие адреса (близко к FFFFFFFF) и расширять (если будет такая нужда) вниз. А можно разместить ядро с нулевого виртуального адреса, а задачи пользователя -- с какого-то более высокого (на самом деле, в большинстве систем в своё время поступали именно так, нынешнее разделение, как я уже говорил, -- наследие VAX/VMS, где оно навязывалось железом). Наконец, виртуальное адресное пространство что ядра, что задач вовсе не обязано быть непрерывным.