Віртуальне та фізичне відображення адрес у 32-бітних Windows

Виправте мене, я помиляюся.

Q1) Я розумію, що в 32-бітовому режимі ми отримуємо віртуальний адресний простір 4 Гб. Це тому, що 32-бітна Windows може підтримувати лише 4 Гб фізичної оперативної пам’яті.

Q2) Кожен процес отримує свій приватний адресний простір у 4 ГБ. Режим користування 2 ГБ і ядро ​​2 ГБ. Чи процес відображає весь код у режимі користувача, і компоненти ОС, необхідні для цього процесу для зв'язку з процесором для виконання коду, завантажуються в режимі ядра.?

Q3) Якщо процес отримує свій приватний 4 Гб місця. Якщо я завантажую 3 процесу, загалом 12 ГБ адресного простору. Чи виникне проблема з продуктивністю, оскільки у мене є лише 4 ГБ оперативної пам’яті.

Але оскільки віртуальна адреса призначена для задоволення потреб процесу у випадку меншої оперативної пам'яті. Так що моє справжнє запитання, коли процес (однопроцесовий додаток) завантажує чи він відображає весь код на віртуальну адресу 4 Гб незалежно від того, що програма зараз виконує лише певну частину всього коду.

Я розумію, що коли запускається процес, весь його код завантажується у віртуальний адресний простір в режимі користувача 2 ГБ, а решта 2 Гб він завантажує файли ядра ОС. Тепер за допомогою таблиць сторінок віртуальна адреса відображається на фізичну адресу в оперативній пам'яті та на диску. Якщо я відмовляюся використовувати файл сторінки, чи означає це, що лише 1 процес з віртуальною адресою 4 Гб може працювати на 32-бітній 4 Гб ОС?

===================================================== =========================== Дякую за попередні відповіді.

Я все ще трохи заплутаний у тому, як розділений простір адрес користувача та ядра.

1) Чи розділяється адресний простір ядра в 2 Гб усім процесом, оскільки він є загальносистемним і завантажується під час завантаження. або Чи кожен процес отримує 2 Гб адресного простору ядра.? 2) Я читаю, що погано написана програма може споживати весь її адресний простір. Чи означає це, що зараз немає місця для запуску інших програм на машині 4 Гб.? 3) Якщо адресний простір ядра є спільним для всіх процесів, чи коли-небудь у нього не вистачає адресного простору, або це ніколи не відбувається, тому що (я думаю) адреса ядра залишається виправленою на основі архітектури ОС і поділяється всім процесом. 4) За допомогою перемикача USERVA адреса ядра зменшується до 1 ГБ лише для додатків із відомою великою адресою. Чому це не робиться для всіх процесів, якщо простір адреси ядра, якщо 2 Гб (що, на мою думку), є спільним для всіх процесів.? 5) Як саме ми розмежовуємо б / ч віртуальну пам’ять та віртуальну адресу. ? Якщо програмі потрібно 5 Гб оперативної пам’яті відповідно до розробника, вона не працюватиме на 32-бітній машині з 2 Гб адресою (чи добре сказати віртуальна пам'ять процесу = віртуальний адресний простір процесу?)

Виправте мене, я помиляюся.

З радістю. Ви готові?

Q1) Я розумію, що в 32-бітовому режимі ми отримуємо віртуальний адресний простір 4 Гб.

Правильно.

Це тому, що 32-бітна Windows може підтримувати лише 4 Гб фізичної оперативної пам’яті.

Ні, розмір віртуальної пам'яті не залежить від розміру фізичної або встановленої пам'яті.
Ці величини однакові лише тому, що вони обидва використовують значення (для адрес), що мають 32 біти. Процесор може бути розроблений таким чином, щоб розмір віртуальної адреси відрізнявся від фізичного розміру адреси. IIRC, що було зроблено ще тоді, коли габаритні розміри та витрати на обладнання були значно більшими, ніж сьогодні.

Q2) Кожен процес отримує свій приватний адресний простір у 4 ГБ.

Так, віртуальний адресний простір.

Режим користування 2 ГБ і ядро ​​2 ГБ.

Ні, "режим користувача" стосується операційного стану процесора, тобто режимів процесора. У пам'яті немає "режиму користувача" (ні режиму ядра).
Віртуальна пам'ять поділяється на простір користувача та простір ядра.

Чи перетворює процес весь код на режим користувача, а компоненти компонента ОС, необхідні для того, щоб цей процес спілкувався з процесором для виконання коду, завантажується в режимі ядра.?

Це питання може мати сенс лише в тому випадку, якщо "режим" замінено на "пробіл".

Ядро завантажується у фізичну пам'ять під час завантаження.
Виконання ядра - це те, що контролює систему, наприклад, запуск та управління процесом.
Ядро відображається у віртуальний адресний простір кожного процесу. Ось чому частина віртуальної пам'яті процесу - це «простір ядра».

Код програми та бібліотеки (спільні) відображаються у віртуальній пам'яті в просторі користувача.

ОС не «спілкується з процесором» (ні якийсь процес).
Процесор / процесор виконує вказівки. Немає "комунікації" з процесором.
Процес - це концептуалізоване завдання або завдання, яким виділяються такі ресурси, як пам'ять (як віртуальна, так і фізична) та запланований час процесора.
Єдина взаємодія між процесом і процесором / процесором - це виконання інструкцій щодо цього процесу. Взаємодія між ядром та процесором / процесором - це виконання інструкцій щодо цього ядра та маршрутизація винятків та переривань.

Q3) Якщо процес отримує свій приватний 4 Гб місця.

Немає "якщо" . Кожен процес отримує 4 ГБ віртуальної пам'яті.

Якщо я завантажую 3 процесу, загалом 12 ГБ адресного простору. Чи виникне проблема з продуктивністю, оскільки у мене є лише 4 ГБ оперативної пам’яті.

Це зовсім не ймовірно, оскільки типові процеси рідко використовують всю свою віртуальну пам'ять. І навіть якщо у них є резервне сховище (наприклад, файл підкачки або простір для обміну) для обробки ситуацій, коли фізична пам'ять менше, ніж віртуальний адресний простір (що є первинною причиною використання віртуальної пам'яті).

Але оскільки віртуальна адреса призначена для задоволення потреб процесу у випадку меншої оперативної пам'яті.

Ви, мабуть, маєте на увазі віртуальну пам’ять, а не «віртуальну адресу» .

Так що моє справжнє запитання, коли процес (однопроцесовий додаток) завантажує чи він відображає весь код на віртуальну адресу 4 Гб незалежно від того, що програма зараз виконує лише певну частину всього коду.

(Чому на ваше "справжнє запитання" не вказано номер?)
Я не маю остаточної відповіді, але сподіваюся, що вона буде завантажувати всю програму, щоб здійснити будь-які переміщення, а також вирішити будь-яке зовнішнє посилання ( наприклад, до бібліотек).
Що б не завантажувалося, має відображатися, тобто виділяється фізична пам'ять.

Я розумію, що коли запускається процес, весь його код завантажується у віртуальний адресний простір в режимі користувача 2 ГБ, а решта 2 Гб він завантажує файли ядра ОС.

Знову ви неправильно використовуєте "режим користувача" .
Завантаження коду ядра виконується під час завантаження, а не при запуску процесу.

Тепер за допомогою таблиць сторінок віртуальна адреса відображається на фізичну адресу в оперативній пам'яті та на диску.

Ні, таблиці сторінок відображають лише віртуальну фізичну пам'ять (в одиницях сторінок). Немає відображення на "диск" . Це звучить як поширене неправильне уявлення про те, як працює файл сторінки та віртуальна пам'ять.
Файл сторінки - це резервне зберігання. Він тимчасово містить вміст сторінок віртуальної пам'яті, які не можуть бути резидентами пам'яті (тобто виділена фізична пам'ять).

Якщо я відмовляюся використовувати файл сторінки, чи означає це, що лише 1 процес з віртуальною адресою 4 Гб може працювати на 32-бітній 4 Гб ОС?

Ні, оскільки зазвичай процес не використовує весь віртуальний адресний простір, тому для нього не потрібно 4 Гб фізичної пам'яті.
Я бачив більше двох десятків процесів, які виконуються в 32-бітній системі Linux із лише 512 МБ встановленої оперативної пам’яті та жодного файлу підкачки.

Q1: Ні, це тому, що 32-розрядний регістр може містити лише 4 ГБ унікальних адрес.

Q2: Неправильно, немає поділу пам'яті користувача на користувача та ядра. Ядро не знаходиться в адресному просторі процесу.

Q3: Так, Windows замінить по мірі необхідності найстаріші сторінки пам'яті.

Справжнє запитання: Так, процес не може розпочатися без відображення для заміни простору всієї його пам'яті, тому його можна будь-який момент повністю або частково замінити.

Для решти, я пропоную вам почитати спочатку у Вікіпедії:

• Адреса пам'яті
• Віртуальний адресний простір
• 64-бітні обчислення