Виртуальные адреса незаметно для приложения сопоставляются с физической памятью за счёт совместной работы железа (MMU, Memory Management Unit) и софта (таблицы страниц, Page Tables). Информация об этих сопоставлениях ещё и кэшируется в самом железе — в TLB (Translation Lookaside Buffer), чтобы дальше быстро находить нужные физические адреса.

Страница — это просто группа подряд идущих линейных адресов в физической памяти. На x86 размер страницы — 4 КБ.

Абстракция виртуальной памяти даёт несколько плюсов:

• Программисту не нужно понимать архитектуру физической памяти на платформе. VM скрывает детали и позволяет писать код, не завязываясь на конкретное железо.

• Процесс всегда видит линейный непрерывный диапазон байт в своём адресном пространстве — даже если физическая память под ним фрагментирована.

Например: когда приложение просит 10 МБ памяти, ядро Linux просто резервирует 10 МБ непрерывного виртуального адресного диапазона. А вот физические страницы, куда этот диапазон будет отображён, могут лежать где угодно. Единственное, что гарантированно идёт подряд в физической памяти — это размер одной страницы (4 КБ).

• Быстрый старт из-за частичной загрузки. Demand paging подгружает инструкции только в момент, когда они реально понадобились.

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

Команда pmap -X <pid> помогает посмотреть, какие области памяти процесса общие с другими, а какие — приватные.

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

• Каждый процесс живёт в своём отдельном виртуальном адресном пространстве и не может вмешиваться в память других процессов.

Два процесса могут использовать одинаковые виртуальные адреса, но эти адреса будут отображены в разные места физической памяти. А вот процессы, которые подключаются к одному сегменту общей памяти (SHM), получат виртуальные адреса, указывающие на одни и те же физические страницы.

Виртуальное адресное пространство процесса состоит из сегментов разных типов: Text, Data, Heap, Stack, сегменты общей памяти (SHM) и области, созданные через mmap. Адресное пространство процесса — это диапазон виртуальных адресов, который ядро «выдаёт» процессу как его среду исполнения.

Каждый сегмент — это линейный диапазон виртуальных адресов с началом и концом, за которым стоит какой-то источник данных (backing store): файловая система или swap.

Ошибка страницы обрабатывается так: ядро поднимает физическую страницу, заполняя её данными из backing store. Когда памяти начинает не хватать, данные из физических страниц, используемых как кеш, сбрасываются обратно в свой backing store. Сегмент Text у процесса опирается на исполняемый файл в файловой системе. А вот стек, куча, страницы COW (Copy-on-Write) и shared memory — это анонимные (Anon) страницы, их хранилище — swap (дисковый раздел или файл).

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

Когда процесс вызывает malloc() или sbrk(), ядро создаёт новый сегмент кучи в адресном пространстве процесса и резервирует диапазон виртуальных адресов, по которому он теперь может легально ходить. Любое обращение к адресу за пределами этих границ приведёт к segmentation fault — и процесс отправится в небытие. Выделение физической памяти при этом отложено: она будет выделена только когда процесс реально обратится к этим виртуальным адресам.

Пример: приложение сделает malloc() на 50 ГБ, но реально коснётся (то есть вызовет page fault) только 10 МБ. Тогда физической памяти уйдёт всего 10 МБ.

Посмотреть виртуальное/физическое потребление памяти можно через “ps”, “pidstat” или “top”. Столбец SIZE показывает размер виртуального сегмента, а RSS — объём выделенной физической памяти.

Физические страницы, которые используются для сегмента Text или для файлового кеша (page cache), можно освобождать быстро — данные всегда можно снова получить из backing store (файловой системы). А вот для освобождения анонимных страниц сначала нужно записать их содержимое в swap, и только потом страница может быть освобождена.

Политика выделения памяти в Linux

Выделение памяти процессам регулируется политикой распределения памяти в Linux. В системе есть три режима, и выбираются они с помощью настройки vm.overcommit_memory.

1.Эвристический overcommit (vm.overcommit_memory=0)

Это режим по умолчанию. Ядро позволяет процессам «переборщить» с запросами памяти в разумных пределах — как решат внутренние эвристики. Они учитывают свободную память, свободный swap, а также память, которую можно быстро освободить, ужав файловый кеш или slab-кеши ядра.

Плюсы: учёт довольно мягкий; полезно для программ, которые обычно запрашивают больше памяти, чем реально используют. Пока хватает свободной памяти или swap, процесс продолжает работать.

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

(знаю, что нынче сравнения в формате плюсы/минусы в статье приравниваются к генерации нейросети, но пока это всё еще лучший вариант описания, так что...)

2.Всегда overcommit (vm.overcommit_memory=1)

С этим режимом процесс может запросить сколько угодно памяти, и запрос всегда будет успешным.

Плюсы: никаких ограничений — можно делать огромные выделения, даже если физической памяти и swap мало.

Минусы: те же, что и в эвристическом режиме. Приложение может сделать malloc() на терабайты при наличии нескольких гигабайт RAM. Пока оно не тронет все страницы, проблем нет — но как только тронет, может включиться OOM Killer.

3.Строгий overcommit (vm.overcommit_memory=2)

В этом режиме ядро запрещает overcommit и резервирует не только виртуальный диапазон, но и физическую память. Нет overcommit — нет и OOM Killer.

При Strict Overcommit ядро отслеживает, сколько физической памяти уже зарезервировано или закоммичено.

Поскольку Strict Overcommit не учитывает свободную память или swap, ориентироваться на free или vmstat бессмысленно. Чтобы понять, сколько памяти можно ещё выделить, смотрят в /proc/meminfo на поля CommitLimit и Committed_AS.

Текущую границу выделения считают так: CommitLimit − Committed_AS.

Настройка vm.overcommit_ratio задаёт предел overcommit’а для этого режима. Предел считается так: PhysicalMemory × overcommit_ratio + swap.

Значение можно поднять, увеличив vm.overcommit_ratio (по умолчанию — 50% от RAM).

Плюсы: OOM Killer не сработает. Лучше, чтобы приложение упало сразу при старте, чем посреди боевой нагрузки от OOM Killer. Solaris работает только так. Strict overcommit не использует free memory/swap для расчёта лимита.

Минусы: overcommit отсутствует полностью. Зарезервированная, но не используемая память простаивает — другие приложения её потрогать не могут. Новый процесс может не получить память, даже если система показывает много свободной RAM — потому что она уже «обещана» другим процессам.

Мониторинг свободной памяти становится хитрее. Многие приложения под Linux не умеют корректно обрабатывать ошибки выделения памяти — это может привести к повреждению данных и странным, трудно отлавливаемым сбоям.

Примечание: и в эвристическом, и в строгом режиме ядро резервирует часть памяти для root. В эвристике — 1/32 от свободной RAM. В строгом — 1/32 от процента реальной памяти, который вы задали. Это зашито в ядро и не настраивается. Например, на системе с 64 ГБ будет зарезервировано 2 ГБ для root.

OOM Killer

Когда система упирается в жёсткую нехватку памяти — файловый кеш уже ужат до минимума, все возможные страницы возвращены — но спрос на память не падает, рано или поздно заканчивается всё, что можно выделить. Чтобы не оставить систему полностью без возможности работать, ядро начинает выбирать процессы, которые можно убить, чтобы освободить память. Этот крайний шаг и называется OOM Killer.

Критерии выбора «жертвы» иногда приводят к тому, что убивается самый важный процесс. Есть несколько способов снизить риски:

• Выключить OOM Killer, переключив систему на строгий overcommit:

sudo sysctl vm.overcommit_memory=2 sudo sysctl vm.overcommit_ratio=80

• Исключить критический процесс из рассмотрения OOM Killer. Но даже это иногда не спасает: ядру всё равно нужно кого-то убить, чтобы освободить память. В некоторых ситуациях остаётся только автоматическая перезагрузка, чтобы восстановить работу системы.

sudo sysctl vm.panic_on_oom=1 sudo sysctl kernel.panic="number_of_seconds_to_wait_before_reboot"

Преимущества файлового кеша

Linux использует свободную память, которую сейчас не заняли приложения, для кеширования страниц и блоков файловой системы.

Память, занятую файловым кешем, Linux считает свободной — она доступна приложениям, как только им понадобится. Утилита free показывает эту память как свободную.

Наличие файлового кеша заметно ускоряет работу приложений с диском:

• Чтение: когда приложение читает данные из файла, ядро делает физический IO и подтягивает блоки с диска. Прочитанные данные помещаются в файловый кеш, чтобы в следующий раз не ходить на диск. Повторное чтение того же блока — это уже логический IO (чтение из кеша), что резко снижает задержки. Кроме того, файловые системы выполняют упреждающее чтение (read-ahead): если замечают последовательный доступ, подгружают соседние блоки заранее, предполагая, что приложению они скоро понадобятся.

• Запись: когда приложение пишет данные в файл, ядро кладёт их в page cache и сразу подтверждает запись (buffered write). Данные в кеше могут многократно обновляться (write cancelling), прежде чем ядро решит, что пора сбросить грязные страницы на диск.

Грязные страницы файлового кеша сбрасываются потоками flusher (раньше звали pdflush). Сброс происходит периодически, когда доля грязных буферов превышает пороговое значение — оно регулируется параметрами виртуальной памяти.

Файловый кеш улучшает производительность IO, скрывая задержки хранилища.

Преимущества HugeTLB и HugePages

Функция HugeTLB в Linux позволяет приложениям использовать большие страницы — 2 МБ или 1 ГБ вместо стандартных 4 КБ. TLB (Translation Lookaside Buffer) — это аппаратный кеш, который хранит отображения «виртуальный → физический» адрес. Когда нужной записи там нет (TLB miss), приходится идти в таблицы страниц в памяти, а это дорогая операция.

TLB-хиты становятся всё важнее из-за растущего разрыва между скорости CPU и памяти, а также из-за увеличения объёмов памяти. Частые TLB miss могут ощутимо просадить производительность.

TLB — ограниченный ресурс на чипе, и ядро Linux старается использовать его максимально эффективно. Каждый элемент TLB может быть настроен на работу со страницами разных размеров: 4 КБ, 2 МБ или 1 ГБ.

Если те же слоты TLB использовать под страницы покрупнее, можно покрывать куда большие области физической памяти:

• 4 KB pages: 64×4 KB + 1024×4 KB ≈ 4 MB

• 2 MB pages: 32×2 MB + 1024×2 MB ≈ 2 GB

• 1 GB pages: 4 GB

Плюсы:

• Большие страницы уменьшают количество TLB miss, потому что один TLB-слот покрывает больше адресного пространства.

• Требуется меньше записей в таблицах страниц, и уровней таблиц меньше. Это сокращает задержки на обход таблиц (2 уровня вместо 4) и уменьшает память, расходуемую на сами таблицы.

• Large Pages фиксируются в памяти и не участвуют в выгрузке при нехватке RAM.

• Снижается частота page fault: один fault может заполнить сразу 2 МБ или 1 ГБ, а не жалкие 4 КБ. Приложение «прогревается» заметно быстрее.

• Если у приложения есть локальность данных, HugeTLB даст выигрыш. Но если оно читает байт там, байт здесь, или прыгает по огромной хеш-таблице, то обычные 4 КБ-страницы могут быть выгоднее.

• Улучшается работа механизма prefetch: крупные страницы устраняют необходимость перезапуска чтения на границах 4K.

Минусы:

• Большие страницы требуют предварительного резервирования. Администратор должен заранее выставить количество страниц: vm.nr_hugepages=<число>

(У Transparent Huge Pages предварительного шага нет.)

• Приложение должно уметь работать с HugePages.

Например, JVM нужно запускать с флагом -XX:+UseLargePages, иначе большие страницы просто лежат без дела.

Посмотреть использование: cat /proc/meminfo | grep -E 'HugePages_|Hugepagesize'

• Для HugePages нужны непрерывные физические участки памяти — 2 МБ или 1 ГБ. На системе, которая работает долго, большая часть RAM может быть уже разрезана на 4К страницы, и запрос на HugePage будет просто нечем удовлетворить.

Вход в крепость осуществляется через длинную галерею.

В те далекие года пушки ещё стреляли ядрами. Но в крепости нашлось и современное нарезное орудие, которое я также покажу.

Галерея выходит на широкую площадку, с которой открывается хороший вид на Гавану. Снизу расположена береговая батарея "12 Апостолов". Вообще, названия многих сооружений крепости имеют библейские отсылки, даже сама крепость известна также как "Крепость Волхвов".

Вход во внутренний двор крепости, справа видно показанную раннее галерею.

Во внутреннем дворе расположена главная казарма и подъем к орудийным позициям. В казарме находилась небольшая церковь и помещение коменданта крепости.

Подъем наверх где до сих пор стоят старые пушки.

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

Но стрелять им уже никогда не придётся. Их эпоха закончилась с появлением современных нарезных орудий с лучшей баллистикой и новыми затворами.

Близость солёной морской воды и сильные ветра буквально разъедают металл. Судя по сохранившимся датам, эти орудия изготавливались (отливались) в начале 19 века.

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

Штурм описан в исторических источниках довольно подробно, можно буквально пошагово отследить действия англичан при осаде и взятии крепости. Перейдем к исторической справке штурма, постараюсь привести его кратко, затронув наиболее интересные моменты.

Штурм крепости проходил в ходе Семилетней войны. В июне 1762 года англичане овладели холмом Ла Кабана, который идеально подходил для обстрела крепости (напомню, крепость строилась для защиты от кораблей, а не от атаки с суши). По какой-то причине испанцы уделили очень мало внимания обороне этого холма, несмотря на приказы командования.

Вид с холма на стены крепости, картина Доминика Серреса.

Толстые стены крепости Эль Морро держали выстрелы английских пушек, так как расстояние до холма было слишком большим. Штурмовать крепость без поддержки артиллерии было невозможно, поэтому англичане начали возводить полевые укрепления и постепенно приближаться всё ближе и ближе ко рву. Пришлось даже копать подземный тоннель в сторону одной из стен.

Вид на крепостные стены и ров.

К 22 июня англичане закончили подготовительные работы и открыли огонь из двенадцати пушек и 38 мортир. Под огнем своей артиллерии англичане разместили батареи в непосредственной близости от крепости. Потери обороняющихся начали расти, в день они теряли до 30 человек. Огонь пушек с близкого расстояния начал приводить к появлению брешей в крепостной стене. Каждую ночь испанцы делали всё возможное, чтобы устранить повреждения, но долго продолжаться это не могло: гарнизон постоянно нёс потери, а выжившие валились с ног от ночных ремонтных работ. В этой ситуации испанцы решились на отчаянный шаг и отправили на уничтожение пушек штурмовой отряд из 988 человек. Успеха они не добились, англичане быстро спохватились и дали отпор.

Наблюдательный пункт на крепостной стене. Англичане вели огонь примерно с холма на заднем плане.

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

Атака английских кораблей, картина Ричарда Пэйтона.

Положение англичан ухудшилось не только из-за пожара, но и из-за начавшихся эпидемий. Более того, приближался сезон штормов, что могло свести на нет все подготовительные работы и поддержку флота. Командованию англичан пришлось срочно снимать часть экипажа и пушек с кораблей для усиления сухопутной артиллерии. К 17 июля англичане при поддержке флотских пушек уничтожили почти все орудия испанцев, которые больше не имели возможности обстреливать позиции атакующих и прикрывать ремонтные работы в крепости. Англичане же полностью овладели инициативой и начали подводить пехоту вплотную к стенам, попутно усиливая огонь батарей. Испанцы вновь предприняли попытку сбить англичан, на этот раз в атаке приняли участие 1300 человек, многие из которых переправились в крепость морем из расположенной рядом Гаваны. Атака вновь была неудачной, англичане не отступили.

Вид с крепостной стены на Гавану. Слева расположен маяк.

24 июля испанцам предложили сдаться, но они продолжили держать оборону. Вскоре англичане получили подкрепление, и всё было готово к решающему штурму. 29 июля испанцы предприняли попытку выбить англичан из рва, но вновь потерпели неудачу.

Затем англичане начали штурм. В час дня они подорвали мощнейший заряд и частично разрушили стену, пехота устремилась в образовавшуюся брешь. В ходе схватки был смертельно ранен командующий обороной крепости, в результате чего испанцы отступили. Англичане получили контроль над крепостью и установили на ней свои орудия. Гарнизон Гаваны сопротивляться уже не мог, вскоре город был сдан. Защитники Эль Морро держали оборону больше месяца.

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

Старая пушка с поворотным механизмом. Слева расположен пороховой погреб.

Пороховой погреб внутри. Отверстия в полу могли использоваться для механизма подачи ядер и пороха из крепости.

Неожиданно для себя я даже обнаружил старый крепостной туалет.

Вид на внутренний двор и главную казарму, в которую я также зашёл.

В крепости есть и отдельная батарея, которая смотрит прямо на Гаванский залив. Орудия здесь установлены уже менее мощные, но зато мобильные.

В этом месте залив достаточно узкий, всего около 350 метров в ширину. Так что меньший калибр пушек компенсировался тем, что стрельба из них могла вестись прямо в упор.

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

Продолжение поста «Крепость со старыми пушками. Описание штурма и осады неприступных стен англичанами»

Команда Технического университета Делфта впервые в реальном времени наблюдала, как ядерный спин отдельного атома переключается между квантовыми состояниями, добившись одноимпульсного считывания состояния через электронную оболочку с помощью сканирующего туннельного микроскопа (STM) и электронного спин-резонанса (ESR). Наблюдалась уникальная стабильность ядерного спина на масштабах порядка 5 секунд, что открывает путь к атомарному квантовому сенсингу и управлению на поверхности твердого тела.

Исследователи использовали STM/ESR-подход, при котором прямое состояние ядра считывается косвенно — по влиянию сверхтонкого (hyperfine) взаимодействия на электронный спин и туннельный ток, давая «ступенчатые» переключения в реальном времени. На одиночном атоме изотопа 49Ti на подложке MgO/Ag реализован быстрый импульсный режим, где скорость измерения превышает скорость естественного флипа ядра, что обеспечило одноимпульсное чтение без усреднения; характерное время стабильности ядерного спина составило около 5 с, тогда как электронный спин релаксирует примерно за 100 нс.

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