Разница х86 - 64х линукс

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

Ну почему ты такой упертый, а? Вот загрузился комп. Допустим ты не заметил разницы на SSD. Но вот ты тыкаешь куда-нибудь и на 32-битной системе у тебя затуп в миллисекунду-другую, а на 64-битной у тебя сразу все срабатывает и моментально отрабатывает и ты не приучаешься постоянно тормозить свои же действия в ожидании реакции системы.

У меня ровно обратное наблюдение. После того как переустановил большинство пакетов (включая браузер) на 64-битные, тормозить стало заметно больше. Время старта браузера (до того момента когда в нём можно открыть лор например) на только что запущеном компе - так вообще в несколько раз выросло, на 32 битах было практически мгновенно, на 64 - окно хоть и открывается, но висит ещё секунд 10.

ИИ говорит, что размер page tables, как правило, пропорционален количеству процессов, а не общему объему физической памяти. И для машины с 32Гб памяти он может варьироваться от нескольких десятков до нескольких сотен Мб.

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

А несколько сот мегабайт уже может быть проблемой при адресном пространстве ядра в 1Гб.

пропорционален количеству процессов

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

И для машины с 32Гб памяти он может варьироваться от нескольких десятков до нескольких сотен Мб.

Если речь именно про процовые таблицы, а не про структуры ядра (которые можно сделать сколь угодно неэффективно), то таблицы трансляции для 32гб памяти таки занимают примерно 64мб. Может быть повышение в случае, когда процесс запросил себе кучу мелких блоков, рандомно разбросанных по разным местам адресного пространства (таблица к 2мбайт зоне занимает 4кб, даже если из этой 2мбайт зоны выделено только 4кб), но обычно такого не происходит.

иначе инженеры Интел не стали бы городить огород с иерархией таблиц. Иеррахия нужна для уменьшения размера page tables.

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

таблицы трансляции для 32гб памяти таки занимают примерно 64мб.

Почему? Там же виртуальный адрес транслируется в физический, а не наоборот. Это на каком-нибудь Итаниуме они инвертированные.

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

[1] Существует shared memory, когда несколько логических блоков (в одном или в разных процессах) ведут на один и тот же физический блок. Им потребуется несколько копий записей в таблицах, хотя физически памяти одна копия. Расход растёт, однако:
а) если доля shm в общем расходе памяти мала (обычно так и есть) - забиваем на эти мелочи
б) если это большие shm-блоки на несколько мегабайт - их можно оптимизировать, в таблицах процесса займётся всего по одной записи на каждые 2(PAE)/4(non-PAE) мбайта - либо ссылку на шаред-таблицу (т.е. расход опять однократный а не многкратный), либо вообще описание большой страницы (если выделенная физическая память не фрагментирована)
в) если это куча мелких shm-блоков, которые нельзя оптимизировать как указано выше, но суммарным объёмом большим - да, будет дополнительный расход, но это редкая ситуация

[2] страницы в свапе, очевидно, физическую память не занимают, но таблицы к ним требуются - это тоже перерасход, однако:
а) обычно стараются в свапе много не хранить
б) если в свапе оказался целиком 2/4-мбайт блок то 4к-таблицу к нему тоже можно убрать в свап
в) плохая ситуация оказывается опять только если есть куча фрагментированной мелочи

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

На том сервере как раз крутилось много оракловых инстансов. Базы были большие, shared memory наверное тоже много.

Может быть, hugepages и помог бы. Но базой управляли не мы.

У меня провисоны в браузере случались до недавнего времени в том числе на этом сайте при открытии формы для ответа до установки Mesa 26. Сейчас вроде как не дергает насильно видеокарту непонятно зачем и соответственно нет затупа секунд на 10. Встройка UHD770 прекрасно справляется на вейланде с вулканом. Это когда в /etc/environment внесена строка WLR_RENDERER=vulkan

Совсем тупняковые сайты вроде pinterest будут лагать что ты с ними ни сделай. Даже если будут прописаны в /etc/hosts адреса серверов это не слишком сильно уменьшит лагованность сайта, который сам по себе может секунд 10 не отдавать данные. У него встроенная тормозуха с просером нескольких блоков спустя какое-то время. gfx.webrender.compositor конечно же включен. Когда держишь страницу на пейдж дауне увидишь как это все со скрипом едва работает. Вот тебе адреса допустим. Можешь сравнить лаги до и после, только браузер надо открывать заново. Если лаги пройдут это значит тебе тормозят DNS ответы, вероятно намеренно. Пакеты с данными тоже могут тормозить, особенно на мобильном интернете.

151.101.64.84 pinterest.com
151.101.236.84 ct.pinterest.com
151.101.236.84 ru.pinterest.com
151.101.192.84 pinimg.com
#128.75.238.144 i.pinimg.com
#128.75.238.168 i.pinimg.com
#128.75.237.41 i.pinimg.com
#2.18.72.143 s.pinimg.com
#23.1.231.29 s.pinimg.com
#2.23.167.72 v1.pinimg.com
#128.75.238.152 v1.pinimg.com