Современная разбивка диска

А как конкретно с использованием свопа связано ограничение адресов виртуальной памяти?

Вот я тоже этого не понял. Хотя могу допустить что при каких-то сверхбольших объемах памяти (сотни гигов) может быть и связано,но не аппаратно конечно,а например из-за каких-то программных ограничений в коде ядра. Просто «сотни гигов» это далеко за пределами конфигураций типичного десктопа,потому я особо и не интересовался.

Надеюсь наш несколько самоуверенный коллега нам эти тонкости пояснит.

Получается это ложь?

https://stackoverflow.com/a/12777127

Что тогда по твоему делает PAE? Как ОС+приложения в целом используют более 4 гб с ним? Что он добавляет?

In computing, Physical Address Extension (PAE), sometimes referred to as Page Address Extension,[1] is a memory management feature for the x86 architecture. PAE was first introduced by Intel in the Pentium Pro, and later by AMD in the Athlon processor.[2] It defines a page table hierarchy of three levels (instead of two), with table entries of 64 bits each instead of 32, allowing these CPUs to directly access a physical address space larger than 4 gigabytes

Ты слова «physical adress space» без подсказки найдешь?

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

Хотя мы тут и недолюбливаем Микрософт,по больше части за проделки Баллмера во времена его там царствования,однако в качестве подтверждения возможности использования 32-разрядными системами более 4 Гб физической памяти можно обратиться к этой странице https://learn.microsoft.com/ru-ru/windows/win32/memory/memory-limits-for-windows-releases К сожалению, столь же информативной страницы для линукса я не нашел. Очевидно что и своп работает ибо винды свопиться очень любят:) И обратите внимание,что даже в включенным PAE в 32-битном режиме не бывает поддержки больше 64Гб физической памяти. Вот как раз именно потому что виртуальные адреса кончаются и происходит именно то о чем вы подумали когда спросили «как можно адресовать своп». Только ограничение не 4 Гб,а 64 Гб.

Получается это ложь?

Насколько я понимаю — да. При использовании pae у тебя нет нескольких независимых виртуальных адресных пространств. У тебя есть «окно» в дополнительную память.

/tmp это ram-диск и я там компилирую ядро

У меня кстати тоже и общесистемный /tmp и ~/.cache в домашнем каталоге примонтированы как «tmpfs»,то есть фактически ram-диск. Хотя я там ядро и не компилирую так как делаю это относительно не часто. Вот,кстати, если забить чем-нибудь такую tmpfs больше чем она сможет разместить в памяти - то система начнет использовать свап.

к диску обращений нету, зачем мне свап то?

«На всякий случай», точно также как и мне. Имеет смысл настроить ранее упомянутого мной демона который сам по надобности создает(и удаляет) свап-файлы. При среднеобычной работе оно ничего не занимает,а если пойдет что-то не так то вместо падения по нехватке памяти система выполнит задачу хотя и с тормозами из-за свопа.

что означает P в аббревиатуре PAE?

Оно означает физическую память. А первый ваш вопрос был про виртуальную. Так вот 32-битные системы могут с PAE поддерживать 64 гига физической памяти. А 64 гига виртуальной - у них есть всегда.

Что ты несёшь?! 32-битность никак не мешает использовать много свапа.

Что касается ускорения работы, то да, часто ускоряет, но не всегда. Вот у меня например так:

$ uptime
 01:51:59 up 25 days,  2:17,  4 users,  load average: 0,71, 0,77, 0,68
$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7,7Gi       2,0Gi       2,1Gi       1,0Gi       3,6Gi       4,1Gi
Swap:           23Gi       685Mi        22Gi
$ cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/sdb2                               partition	16777212	0		-2
/dev/zram0                              partition	7812496		701732		10

У тебя 64 битной ядро. А у него 32 битной. Почувствуй разницу

Неужели ты так и не понял?

Не понял. Поясните если не Лень. А то вон коллега утвержает что на 32-битных системах с установленными более 4 Гб памяти свап работать не может. Хотя это легко опровергается любым человеком кто ставил такую систему на машину с большим объемом памяти.

При использовании pae у тебя нет нескольких независимых виртуальных адресных пространств.

Независимые виртуальные адресные пространства есть у каждого процесса даже без PAE. Многие .exe под Windows могут работать только если загружены по строго определенному адресу.

Про окно у тебя странное представление, наверное что то такое было до PAE. Вроде под DOS, было прерывание что бы получить в первый мегабайт память за его пределами.

Я не вижу там информации о том, как адресовать свап в 32 битной системе, если у тебя 4 гигабайта ram, а ядро зарезервировано под свои нужды гигабайт виртуальных адресов

А 64 гига виртуальной - у них есть всегда.

Эм, нет. Смотря как считать, но точно не 64 виртуальной. Обычно считают как 4гб. Если посчитать с учётом сегментирования (про которое hateWin наверно не знает) - будет 64 терабайта (тера - не гига), и это на один процесс.

Но к чему эти расчёты я не знаю, на работу линуксового свапа это не влияет.

У меня 32-битное.

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

Адресация свапа вообще никак не связана с архитектурой проца. Проц не знает ни про какие свапы, эта абстракция целиком на стороне ОС. Со стороны проца есть только битовый флаг «эта виртуальная страница такого-то процесса отсутствует в физической памяти», и когда процесс к ней обращается - проц передаёт управление ОС чтобы та разобралась что делать дальше. И это разбирательство - не всегда чтение её из свапа, кстати.

Он думает что 4 гб виртуальной памяти это общее количество на всю систему, и трансляция общая для ядра, процессов. Поэтому ты типо транслируешь 4 гб на физическую, и все. Если что то заберешь под свап, то лишишься доступа к физической.

Нисколько не спорю,у вас некий особый случай когда вы были вынуждены по каким-то важным причинам не только купить за свои деньги плату с распаяными на ней wifi и bt,но и использовать обязательно их,а не внешние. Кстати,а как в этом случае решается вопрос с антеннами того и другого если корпус металлический как это типично бывает? Или пришлось покупать какой-нибудь «дизайнерской» корпус с пластиковой [обычно прозрачной]стенкой?

У NVidia с драйверами все лучше

Именно поэтому у меня в «большом» компе тоже NVidia,хотя и «морально устаревшая». Я там экспериментировал с OpenCL. И кстати опять наткнулся на то,что для каких-то существенных вычислений мало памяти (той что на карте). К сожалению,нет простого способа ее туда добавить,даже хорошо владея пайкой как я.

Независимые виртуальные адресные пространства

Которые являются подмножеством одного и тоже виртуального адресного пространства. В случае с PAE виртуальное адресное пространство будет одно. У процессов будет доступ к «дополнительной» памяти, но виртуально адресное пространство от этого не расширится

Которые являются подмножеством одного и тоже виртуального адресного пространства.

Нет, не являются. 4гб пространство процесса (нарезанное на страницы по 4кб, 2мб и 1гб) мапится напрямую на страницы в физической памяти (когда-то с 36-битными адресами, сейчас больше). У другого процесса они могут мапиться как на полностью другие физические, так и иметь общие (обычно это ядро и всякое юзерспейсное shared). Те страницы, что в свапе, на уровне проца мапятся вникуда (у них нет физ. адреса вообще) и их может быть сколь угодно много, выяснять с какого сектора какого диска их читать будет ОС по любым закоденным её авторами алгоритмам.

Это ограничение виртуального адресного пространства в целом.

Нет,ограничение виртуального - 64 Гб. Даже на 80386. Другой вопрос что проц не может всё это адресовать как единый кусок,только через трансляцию. И это наследие 8086,где общее адресное пространство было 1 мегабайт,но непрерывная адресация только в пределах сегмента 64К. Поэтому в программе нельзя было без извращений создать масив размером больше 64К. Ну а на 32-битных системах вместо 64К ограничение 4Гб. Но программ,которым были бы реально нужны непрерывно адресуемые куски памяти по 4Гб - вобщем довольно мало и кучкуются они в достаточно специфичных областях типа например видеомонтажа.

PAE – чудовищный костыль.

Ну костыль или не костыль - а он есть,работает и ядро умеет им пользоваться. Честно говоря, в х86 процах вообще костыль на костыле и костылём погоняет. Но они [пока] самые производительные. А в последние лет десять и энергоэффективность существенно подтянули.

это касается физической памяти, а не виртуальной

Да,именно так. А вы спрашивали органичение виртуальной. Я ответил именно это - 64 Гб.

Я сейчас сделал поиск в DNS по чипсету z890, и только 3 из 21 мат.плат НЕ имеют встроенного WiFi. Я им кстати не пользуюсь, а антента прикручивается сзади если нужно, там же где разъемы USB.

А то вон коллега утвержает что на 32-битных системах с установленными более 4 Гб памяти свап работать не может. Хотя это легко опровергается любым человеком кто ставил такую систему на машину с большим объемом памяти.

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

А если в официальных терминах (Intel Manual), как называется общая область из которой черпается виртуальная память для процессов?

Нет,ограничение виртуального - 64 Гб

Каким образом ты собрался 32 битными указателями адресовать 64 гигабайта виртуальной памяти?

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

Через виртуальную память. Процесс не знает где он находится в физической памяти. Поэтому даже будучи загруженным на 40 гб, он думает что расположен в первых 4гб. Его обращения к виртуальной памяти (а только такая у него есть) транслируется через таблицу в физическую.

Что тогда по твоему делает PAE?

PAE добавляет битов в адреса физической памяти. А коллега меня спросил про виртуальную,адреса которой преобразуются в физические через трансляцию,да еще и многоуровневую. И виртуальных адресов 64Gb даже на 80386.

Кстати, Линус поленился хорошо разобраться с механизмом трансляции 80386 когда придумывал работу с памятью для своего курсовика и не задействовал как следует сегментный механизм и самое главное - имеющиеся в нем возможности защиты памяти. Запихал всё в один сегмент. У него фактически только страничный механизм трансляции работал. Потом вроде это немного допилили и ядро поместили в отдельный сегмент,но тут могу ошибаться в тонкостях,давно туда не заглядывал.

PAE добавляет битов в адреса физической памяти.

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

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

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

В свапе какие-то 700М, при этом 2G памяти вообще не распределено, то есть эти 700М можно было там и оставить

Да вот я уже сколько раз говорю об этом же,но кое-кто громко объявляет мои слова чушью.

Причем если к установленным у вас 8 Гб добавить еще одну планку на 8 Гб то свап вообще пустой будет,без каких-либо перенастроек.

Так что ОС просто зря потратила время на зеркалирование этих страниц в свап.

Полностью с вами согласен.

Но да, это частный случай, конечно не всегда так.

Я считаю что при нынешних ценах на память имеет смысл ее добавлять и от подобных «частных случаев» избавляться,как минимум на среднетипичном десктопе.

Вон выше другой коллега писал что поставил 32 гига и аж ядро компилирует на ram-диске при вообще выключенном свопе.

Причем если к установленным у вас 8 Гб добавить еще одну планку на 8 Гб то свап вообще пустой будет,без каких-либо перенастроек.

↑ А потом «почему-то» оказывается, что «кое-кто громко объявляет мои слова чушью». Интересно, почему бы…

как адресовать свап в 32 битной системе, если у тебя 4 гигабайта ram

Виртуальное адресное пространство даже у 386 процессора (он без PAE) - 64 гига. Вот туда и адресовать. Еще раз подчеркиваю - виртуальное. А PAE - это про доступ к физической памяти за пределами четырех гигов.

Ну и возвращаясь к началу - вы все еще утверждаете что на 32-битный системах при установленных 4 и более гигов памяти свап вообще не может работать? Комп именно с четырьмя гигами памяти у меня есть(моноблок от Асус),32-битный дебиан на нем есть. Мне поискать чем забить память чтобы свап стал не нулевой? Или на слово поверите что не нулевой он у меня изредка бывает? Есть и комп с 16 Гб и тоже 32-битным дебианом,но забивать столько памяти просто разным софтом я точно запарюсь. Так что начнем с меньшего.

Кстати,может подскажете чем проще всего забивать память до появления свапа,ну кроме очевидного запуска кучи софта и открытия в нем больших файлов? Может есть какой-нибудь «команднострочный» трюк?

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

Смотря как считать,тера - не гига

Вобщем да,согласен с вами,можно и 64 терабайта насчитать.

Русская Википедия считает только страничное преобразование:

«Через страничное преобразование i386 может адресовать до 4 Гбайт физической памяти и до 64 Гбайт виртуальной памяти.»

Английская Википедия помнит про сегментный механизм и насчитала 64 Терабайта:

«With the addition of segmented addressing system, it can expand up to 64 terabytes of virtual memory.»

Но как уже упоминал выше, Линус в юности схалявил, с сегментным механизмом и его пользой подробно разбираться не стал и его фактически не задействовал. Поэтому для именно Линукса будет более применима цифра 64 Гигабайта.

на работу линуксового свапа это не влияет.

Вот и я о том же говорю. А меня тут кое-кто усердно пытается высмеивать. Только я не поддаюсь:)

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

У меня зависаний из за памяти нету

Так у вас там памяти настолько много что аж для компиляции ядра на ram-диске хватает. Если вдруг кончится даже такое количество памяти - то да,скорее всего это [пред]аварийная ситуация и надо убивать программу которая смогла сожрать столько.

Через страничное преобразование i386 может адресовать до 4 Гбайт физической памяти и до 64 Гбайт виртуальной памяти

Это какое-то враньё. Никакие «64гб виртуальной» там никак не получится насчитать. Либо 4гб (без сегментов) либо 64тб (с ними).

Поэтому для именно Линукса будет более применима цифра 64 Гигабайта.

Нет, см. выше. 64гб возникает ровно в одном месте - как лимит физической адресации ранних процов с PAE и больше нигде.

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

И полная установка Slackware со всех дисков, помещается в 16 гб памяти, и остается 6 гб под процессы, так что результат ожидаемый. Обычно ставят более минималистичные системы, из дистрибутивов которые ставятся с большим количеством софта по умолчанию я знаю только Slackware.

4 гб виртуальной памяти это общее количество на всю систему, и трансляция общая для ядра, процессов.

Примерно так и было в очень древних ядрах 1.Х в 90х годах,тех которые еще были x86-only.Там всё было запихнуто в один четырехгигабайтный сегмент. Учитывая что в те времена память в компах измерялась единицами-первыми десятками _мега_байтов - оно было относительно допустимо. Ну примерно также как «640К хватит всем»(С) и довольно долго вполне хватало.

Которые являются подмножеством одного и тоже виртуального адресного пространства.

Хватит уже чушь нести (С) некто hateWin :-)

Вон тут уже появился уважаемый firkax,который помнит аппаратную архитерктуру x86 еще и получше меня,в чем я уже убедился эдак полгода назад в одной из тем тут же на Лоре. Всё же я активно копался в этом аж еще в 90х и с тех пор некоторые тонкости подзабыл. А последние десяток-полтора лет только в микроконтроллерном железе копаюсь.

А вам,если интересно,порекомендую книжку «Микропроцессор 80386 и его программирование»(автор Брамм,издательство Мир). У меня «настольной» была когда-то именно она. Ну или любую другую «толстую» книжку именно по 386 потому что механизмы адресации лучше всего разжеваны именно там,и они почти идентичны 32-битному режиму современных процов.

Эх,тридцать лет прошло,теперь эти мои знания никому не нужны,а тогда были настолько востребованы что даже деньги приносили. А главное - это было интересно, в отличие от всяких современных фреймворков с их нагромождением абстракций над абстракциями:(

чипсету z890

Я и говорю что у вас были свои важные причины покупать плату именно на этом чипсете.

встроенного WiFi. Я им кстати не пользуюсь

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

почему при положительном swappiness и многих днях аптайма свап не используется.

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

ровно 4 ГБ оперативы это слишком хорошо объясняют.

Так это у меня в довольно экзотическом моноблоке от Асуса столько воткнуто потому что там всего один разъем,а сам этот моноблок - для лазания по форумам,почтовой переписки,чтения всяких даташитов по электронике и музыкального сопровождения этих действий. В соседней комнате стоит «большой» комп с 16 Гб памяти,ядро ее видит и использует,ну и если очень постараться чтобы чем-то ее занять то будет использовать свап. Только там он не на разделе,а в автоматически создаваемых специальным демоном файлах. Собственно, свап-раздел на моноблоке появился когда-то потому что я опасался что памяти будет часто не хватать(браузеру) и автоматическое создание свап-файлов будет приводить к тормозам(пока создается). Оказалось что нет - более чем достаточно. Даже при заходе на толстые сайты типа Авито. Более того,этот моноблок тянет без свапа даже KiCAD с несложными схемами когда лень идти включать большой комп (та комната угловая и в ней прохладнее,компу-то хорошо,а я лучше тут у печки:)

Я и говорю что у вас были свои важные причины покупать плату именно на этом чипсете.

А других чипсетов для этого поколения нету. Вот z790 и b790 есть, но b790 не предназначен для разгона и более урезана. Короче это дефолт сейчас.

В будущем возможно будет таким же стандартом как и аудиокарта.

Тем более что вообще идея подключать именно десктоп через wifi для меня выглядит странно.

Если лень тянуть кабель. Я так подключался, но раньше.

Я несколько не уловил логику.

Меня волнует только что P/E ядра процессора плохо обрабатываются планировщиком в старых ядрах linux.

Каким образом ты собрался 32 битными указателями адресовать 64 гигабайта виртуальной памяти?

Через механизм трансляции,где к 32 битам добавляется еще. Но вот непрерывным куском,без переключения трансляции(загрузки сегментного регистра), адресовать можно только 4 Гб - тут вы правы. Поэтому ограничение виртуальной памяти на процесс и есть четыре гига. Так это на один процесс,и то потому что механизм трансляции так настроен в линуксе (недоиспользуется). Как справедливо добавил коллега firkax, при импользовании нескольких сегментов можно в рамках одного процесса адресовать и больше. Но линукс сегментную модель памяти увы не умеет.

Когда-то я писал код под PharLap DOS Extender,так вот он сегментную модель таки умел. Причем даже и на 80286,где сегменты были всего по 64К и любой хоть сколько-нибудь сложный процесс использовал более одного сегмента. Стоил этот экстендер что-то около 800 тех баксов тридцатилетней давности:( И 16-битный по своей конструкции 80286 адресовал не один,а несколько мегов памяти. У меня на рабочей машине было сначала два,потом четыре. Каждый мегабайт стоил $43. Вот тогда да - приходилось экономить,боролись за каждый _кило_байт.

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

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

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

А потом «почему-то» оказывается, что «кое-кто громко объявляет мои слова чушью». Интересно, почему бы…

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

А я памяти таки добавил и у меня своп пустой. Обычно пустой,хотя и не абсолютно всегда.

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

Если говорить о терабайтах, то мне в голову приходят базы данных. В мануалах для некоторых из них советуют отключать системное кеширование, потому что БД сама его контролирует в своих буферах, и их не рекомендуется настраивать на размеры превышающие память. Кешируются приоритетно индексы, и в мануале по MySQL вроде советовали всегда иметь память которая равна или превышает размер индексов.

где то что то слышал, и теперь твердо убежден.

Будьте пожалуйста снисходительны - один человек не может знать всё и попробовать всё. Я вон тоже верю «где-то услышанным» рассуждениям о ресурсе и износе ssd хотя лично у меня еще ни один ssd не сдох. Но у меня видимо нагрузки на дисковую подсистему не те.

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

Уточню - не «твердо убежден»,а обоснованно предполагаю исходя из цифр задействования свопа.

что почему-то это считается достижением

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

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

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