[32 бита][swap vs. no swap]Внезапно...

выделяет, не оглядываясь на ограничения архитектуры

Это как так? Больше 2ГБ на процесс уж точно не выделит.

Своп не нужен (разве только для гибернейта). 32разрядная архитектура тоже не нужна.

Но можно выделить трём процессам по 2 Гб, логично?

(кроме того, некоторые оффтопичные ОС умеют и по 3 Гб на процесс, да)

Присоединяюсь к вопросу и задаю свой.
На Яндексе есть вопрос:
Есть сервер с Linux, на котором 4 ГБ RAM и 2 ГБ swap.
Что нужно сделать, чтобы общий объем распределяемой памяти в системе стал равным 9 ГБ?
Самообразования ради - что такое «общий объем распределяемой памяти» и как он может быть равен 9 Гб?

> 32разрядная архитектура тоже не нужна.

Ну тут кому как - у меня дома пока всё 32-хразрядное, например, потому как денег на ненужные вещи жалко (а 64-хбитные архитектуры мне дома пока не нужны Ж;-) ).

Хм. Пентиум-3? :)

Не знаю, что такое «общий объем распределяемой памяти», но настройка выделяемой виртуальной памяти на процесс сидит где-то в /proc и в том числе можно её отрегулировать в зависимости от имеющейся физической памяти (физическая=ram+swap).

> (кроме того, некоторые оффтопичные ОС умеют и по 3 Гб на процесс, да)

Некоторые топичные системы умеют 4Gb на процесс еще со времент RedHat 9.

в /proc/sys/vm/overcommit_ratio выставить 140 процентов, а в /proc/sys/vm/overcommit_memory выставить ноль, тогда malloc сможет вернуть 9 гигов

4+4 = user_space+kernel_space ? Это было только в RHEL4 и делалось хитрожопым костылем, в RHEL5 от этого отказались и вернулись к стандартной схеме 3+1

«Ты знал, ты знал!..» Ж;-) И Pentium 4 тоже.

Ну так глубоко я в них не залезал, ибо не надо было.

Интересно, начнутся ли какие-нибудь артефакты в системе после такого воздействия.

proof

Ничего не будет. Если процесс полезет за памятью, которой физически нет, то он будет убит.

Непонятно, зачем тогда требуется такой финт, если пользы от него никакой.

очевидно, что чтобы спросить на собеседовании в яндексе :)

Так что, основное ограничение 32-битной архитектуры задается в единицах «Gb на процесс»? А чем тогда определяется предельный полный объем выделенной памяти на всю систему (нельзя же ведь на 32-битной системе запустить 10 процессов и выделить каждому 2 гига, тем самым в сумме получить 20 гигов)?

Естественно, на 32х битной это не так будет работать. Там 3 гига на процесс максимум и никакими настройками это не увеличишь.

полный объем выделенной памяти на всю систему

такого понятия не существует

нельзя же ведь на 32-битной системе запустить 10 процессов и выделить каждому 2 гига, тем самым в сумме получить 20 гигов

можно

> Ну тут кому как - у меня дома пока всё 32-хразрядное, например, потому как денег на ненужные вещи жалко (а 64-хбитные архитектуры мне дома пока не нужны Ж;-) ).

Значит у тебя уже довольно старая система в которой не только 64 бит нет, но и многие другие вещи уже под вопросом. Потому что в последние лет 5 практически все процессоры для десктопа выпускаются 64-битными. 32-бита - это только Low-end и специальные решения, вроде Atom. При том, сейчас еще надо хорошо поискать low-end именно 32-битный, но кажется у AMD есть самая младшая модель в линейке. Год назад еще была.

> Непонятно, зачем тогда требуется такой финт, если пользы от него никакой.

Затем, чтобы можно было статически выделить память «с запасом». Так, в 77 фотране не было встроенных средств динамического выделения памяти и многие массивы приходилось выделять статически, на этапе компиляции. Чтобы программа могла работать, нужно ей разрешить выделять (но не использовать) объемы, превышающие размер имеющейся памяти (оператива+своп) в системе

Я всё это отлично и сам знаю. Включая точный возраст своей системы (более 10 лет на самом старом из компов по самым старым компонентам). Ж;-)

Вопрос-то совсем не в этом...

> Так что, основное ограничение 32-битной архитектуры задается в единицах «Gb на процесс»?

На виртуальное адресное пространство процесса, причем «нижние» 3 Gb отводятся под кучу, стэк и сегменты кода, в в «верхний» гигабайт отображаются адреса вызовов системных процедур.

>1. Имеем 32-хразрядную архитектуру;

2. Имеем 4 Гб ОЗУ физически;

3. Имеем предел доступного адресного пространства для 32-хразрядной архитектуры, равный 4 Гб (PAE отключено);

Так без PAE ты все свои 4Гб адресовать не сможешь.

в «верхний» гигабайт отображаются адреса вызовов системных процедур.

Всегда интересовало, зачем целый гигабайт на это выделять? Сколько там этих системных процедур, несколько десятков, ну может сотен. Ну пусть 64 килобайта будет, хватит каждой домохозяйке. Но зачем гигабайт?

> Так без PAE ты все свои 4Гб адресовать не сможешь.

Э-э... С чего это?! Мы же говорим не в контексте конкретного прикладного процесса, а системы в целом.

> Всегда интересовало, зачем целый гигабайт на это выделять?

Очевидно, если адреса отличаются на 1 бит в старшем разряде, то и получится, что они отделены гигабайтом.

> Так без PAE ты все свои 4Гб адресовать не сможешь.

Сможешь - см. выше обсуждение патча 4G/4G

Ну хорошо, 2-мя битами :)

Предлагаешь всем владельцам нетбуков годовой давности (да и не только) их взять и выкинуть?

И ARM тоже не нужен?

(кроме того, некоторые оффтопичные ОС умеют и по 3 Гб на процесс, да)

Это зависит от настроек, как линуксе, так и в винде.

Спасибо, кэп. Ж;-)

>> нельзя же ведь на 32-битной системе запустить 10 процессов и выделить каждому 2 гига, тем самым в сумме получить 20 гигов

можно

Так откуда же ограничения на объем плашек памяти который можно использовать 32-битным оффтопиком? Все же знают что больше 4 гигов втыкать смысла нет если у тебя 32-битная система.

Выходит что система считается как один процесс, а все программы которые в ней запускаются используют память доступную этому процессу и ни битом больше? Зачем тогда писать ограничения в «Gb на процесс» когда в реальности ограничения измеряются в Gb?

>адреса вызовов системных процедур

Там всё ядро сидит, не? Ядро же не переключает контекст процесса по прерыванию.

Процессор просто не может адресовать >4 гигов _физической_ памяти без пае. Виртуальная память же выдаётся на процесс и в сумме по всем процессам её может быть гораздо больше 4 гигов. И кстати, даже с пае виртуальной памяти на процесс у тебя всё равно будет 4 гига.

> Там всё ядро сидит, не? Ядро же не переключает контекст процесса по прерыванию.

Это ж виртуальное адресное пространство! Просто список адресов. Как уж производится трансляция на деле — это лучше в мануалах по системному программированию защищенного режима x86 процессоров искать.

Резюме: верным было моё последнее предположение, и swap имеет смысл при необходимости запустить, скажем, 2 процесса, требующих по 2 Гб памяти (в этом случае swap никак не может быть меньше 2 Гб при 4 Гб физической).

Быстрый поиск по «диспетчер виртуальной памяти» такого однозначного ответа не дал. Везде (ну, по первым 5 ссылкам) было написано про «позволяет использовать объём памяти, больший имеющегося физически», но нигде никак не упоминалось про соотнесение такой возможности с пределом, определяемым разрядностью.

Щито? Если уж и искать это, то не в мануалах, а в исходниках и документации ядра. И причём тут вообще отображение, если я про то, где как раз логически расположено ядро?

> И причём тут вообще отображение, если я про то, где как раз логически расположено ядро?

Ядро (код) расположено в физической памяти, а мы говорим о виртуальном адресном пространстве процесса. Физическая память может быть (и должна быть) отображена в пространства разных процессов, и вообще говоря, разными способами. Так что читаем мануалы.

Ядро (код) может и в свопе лежать (хотя не знаю точно как в линуксе это сделано), но очевидно, что оно должно быть в логическом адресном пространстве каждого процесса (на что и отводится верхний гигабайт), потому что контекст процесса при переключении в ядро (т.е. при прерываний) не меняется. Хотя может там лежать только заглушка и контекст меняться, это зависит от конкретной реализации в конкретной ОС.

> Ядро (код) может и в свопе лежать

Ядро в свопе? Слабовато верится. Но я не буду утверждать, не в курсе.

потому что контекст процесса при переключении в ядро (т.е. при прерываний) не меняется.

ОК, предлагаю дискуссию закончить, т.к. я потерял ее смысл.

> Ядро (код) может и в свопе лежать

Далеко не всё. Целиком там лежать оно не может.

Ты сказал фразу, в которой, в общем-то был прав, но она звучала как-то неясно для меня. Я попытался уточнить, а ты начал отправлять меня к мануалам по системному программированию, что неверно, потому что эти вещи зависят от конкретной реализации, и утверждать, что я не прав.

ОК, ты умный, я — дурак :) Так пойдет?

>>физической памяти (физическая=ram+swap).

т.е. виртуальной в обычном понимании.

ога, в «обычном» понимании еще системный блок это на самом деле «процессор» :)

Виртуальная память это локальное свойство процесса, а не системы. И физически она может отображаться не только на ram и swap, но в другие места. Например, в видеопамять, в файлы и т.д. и т.п.

>Так откуда же ограничения на объем плашек памяти который можно использовать 32-битным оффтопиком?
Так их и нет в общем случае. Win2000 и 2003 в некоторых редакциях, например, нормально работает с PAE с >4gb памяти. Ограничение в 4гб памяти в винде искусственное.

Позволю себе переформулировать: ограничение на объём памяти - естественное, а вот блокировка PAE - та да, искусственная.

>Ничего не будет. Если процесс полезет за памятью, которой физически нет, то он будет убит.

Не совсем так, насколько я понимаю. Если он просто такой кусок попросит, то действительно - ничего. В иных случаях - имеет шансы поднять iowait на своппинге до неприличных значений. Задав ограничения подобного можно избежать.

Я, кстати, ради интереса пробовал настраивать жесткие лимиты, всё работает нормально, кроме флеша и жабы - полтора гигабайта им оказалось мало.