Что содержит виртуальная память ядра каждого процесса?

Когда говорят, что в память загружаются 3 программы (исполняемые файлы), макет может выглядеть примерно так:

alt text http://img97.imageshack.us/img97/3460/processesm.jpg

У меня есть следующие вопросы:

Является ли понятие виртуальной памяти ограничено пользовательскими процессами? Потому что, мне интересно, где находится ядро операционной системы, драйверы? Как его макет памяти? Я хочу узнать больше о памяти ядра. Я знаю, что его конкретная операционная система делает ваш выбор (windows/linux).
Является ли концепция виртуальной памяти на каждый процесс? Я имею в виду, правильно ли мне сказать 4 ГБ процесса1 + 4 ГБ процесса2 + 4 ГБ процесса3 = 12 ГБ виртуальной памяти (для всех процессов). Это звучит не так. Или из всего 4 ГБ пространства 1 ГБ берется ядром, а остальные 3 ГБ - это общий доступ к всем процессам.
Говорят, на 32-битной машине в адресном пространстве 4 ГБ. Половина его (или совсем недавно 1 ГБ) занята ядром. На этой диаграмме я вижу, что "Виртуальная память ядра" занимает 0xc0000000 - 0xffffffff (= 1 ГБ). Они об этом говорят? Или что-то еще? Просто хочу подтвердить.
В чем точно содержит Kernel Virtual Memory каждого из этих процессов? Каков его макет?
Когда мы делаем IPC, мы говорим об общей памяти. Я не вижу никакой памяти, разделяемой между этими процессами. Где он живет?
Ресурсы (файлы, реестры в окнах) являются глобальными для всех процессов. Таким образом, таблица описаний ресурсов/файлов должна находиться в некотором глобальном пространстве. В какой области это будет?
Где я могу узнать больше об этом материале ядра.

Ответ 1

Когда система использует виртуальную память, ядро также использует виртуальную память. Windows будет использовать верхние 2 ГБ (или 1 ГБ, если вы указали ключ /3GB в загрузчике Windows) для собственного использования. Это включает в себя код ядра, данные (или, по крайней мере, данные, которые выгружались - это право, Windows может вывести часть явного адресного пространства на жесткий диск) и таблицы страниц.
Каждый процесс имеет свое собственное адресное пространство VM. Когда происходит переключение процесса, таблицы страниц обычно заменяются другой таблицей страниц процесса. Это просто сделать на процессоре x86 - достаточно будет изменить базовый адрес таблицы страниц в управляющем регистре CR3. Все адресное пространство 4 ГБ заменяется таблицами, заменяющими совершенно другое адресное пространство 4 ГБ. Сказав это, обычно будут областями адресного пространства, которые разделяются между процессами. Эти регионы отмечены в таблицах страниц специальными флагами, которые указывают процессору, что эти области не нуждаются в недействительности в процессоре translation lookaside buffer.
Как я упоминал ранее, код ядра, данные и таблицы страниц сами должны быть расположены где-то. Эта информация находится в адресном пространстве ядра. Возможно, что некоторые части кода ядра, данных и таблиц страниц сами могут быть заменены на диск по мере необходимости. Некоторые части считаются более критичными, чем другие, и никогда не заменяются вообще.
См. (3)
Это зависит. Совместная память в режиме пользователя находится в адресном пространстве пользовательского режима. Части адресного пространства в режиме ядра вполне могут быть разделены между процессами. Например, было бы необычным, чтобы код ядра был разделен между всеми процессами в системе. Где эта память находится не точно. Я использую произвольные адреса здесь, но разделяемая память, расположенная в 0x100000 в одном процессе, может находиться в 0x101000 внутри другого процесса. Две страницы в разных адресных пространствах с совершенно разными адресами могут указывать на одну и ту же физическую память.
Я не уверен, что вы имеете в виду здесь. Открытые дескрипторы файлов не являются глобальными для всех процессов. Файловая система, хранящаяся на жестком диске, является глобальной для всех процессов. В Windows управление файлами осуществляется ядром, а объекты хранятся в адресном пространстве ядра и управляются диспетчером объектов ядра.
Для систем на базе Windows NT я бы рекомендовал Windows Internals, 5ed от Марка Руссиновича и Дэвида Соломона

Ответ на комментарий:

И теперь этот 3 ГБ является общим б/у всем процессы? или каждый процесс имеет 4 ГБ пространство?

Это зависит от ОС. Некоторые ядра (такие как L4 microkernel) используют одну и ту же таблицу страниц для нескольких процессов и разделяют адресные пространства, используя segmentation. В Windows каждый процесс получает свои собственные таблицы страниц. Помните, что даже если каждый процесс может получить свое собственное виртуальное адресное пространство, это не означает, что физическая память всегда отличается. Например, изображение для kernel32.dll, загруженное в процесс A, совместно используется kernel32.dll в процессе B. Большая часть адресного пространства ядра также разделяется между процессами.

Почему каждый процесс имеет ядро виртуальная память?

Лучший способ подумать об этом - спросить себя: "Как будет работать ядро, если оно не будет выполняться с использованием виртуальной памяти?" В этой гипотетической ситуации каждый раз, когда ваша программа вызывала переключение контекста в ядро (допустим, вы сделали системный вызов), виртуальная память должна была быть отключена, когда процессор выполнялся в пространстве ядра. Там стоит это сделать, и там стоит вернуть его обратно, когда вы переключаетесь обратно в пространство пользователя.

Кроме того, предположим, что программа пользователя передана указателем на некоторые данные для ее системного вызова. Этот указатель является виртуальным адресом. У вас отключена виртуальная память, так что указатель должен быть переведен на физический адрес, прежде чем ядро сможет с ним что-либо сделать. Если вы включили виртуальную память, вы получите это бесплатно благодаря блоку управления памятью на CPU. Вместо этого вам придется вручную переводить адреса в программном обеспечении. Там есть всевозможные примеры и сценарии, которые я мог бы описать (некоторые из которых связаны с оборудованием, некоторые из которых связаны с обслуживанием таблицы страниц и т.д.), Но суть в том, что гораздо проще иметь однородную схему управления памятью. Если пространство пользователя использует виртуальную память, будет легче написать ядро, если вы сохраните эту схему в пространстве ядра. По крайней мере, это был мой опыт.

будет только один экземпляр ОС ядро право? то почему каждый процесс имеет отдельное виртуальное пространство ядра?

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