Оперативная память на 32-бит ОС

[SG]

 Добрый день!
 Лайв стартеркита 32-бит с сохранением, используется на 3-4, разной конфигурации, компах, с 4Гб ОЗУ, DDR3. Этому лайву доступно на них 3100-3350Мб. По случаю, достался новый комп, тоже 4Гб ОЗУ, DDR4. И на нём доступно в полтора раза меньше ~ 2250Мб из 4Гб установленных. В некоторых ситуациях маловато.
 Теоретически, это нормальное явление, (связанное с конкретным железом) определять 55% от 4-х гиговой планки?  Или что-то где-то нужно подкручивать?

P.S. 64-бит и PAE видят количество памяти правильно. Но с ними недостатки другого плана.

[asy]

> Теоретически, это нормальное явление, (связанное с конкретным железом) определять 55% от 4-х гиговой планки?

Скорее да, чем нет. А чем не нравится x86_64?

[SG]

 64-бит ест памяти побольше, заметно. Она эти 4 гига съест как 32-х-доступные 2Гб.
А с ПАЕ видео на полном экране теряет качество, до и нет лайва с ПАЕ.

[Speccyfighter]

Лайв стартеркита 32-бит с сохранением
...
 Теоретически, это нормальное явление, (связанное с конкретным железом) определять 55% от 4-х гиговой планки?

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

Или что-то где-то нужно подкручивать?

Ищите в BIOS опцию Remap memory и выключайте её.
Эта опция BIOS может быть в самых разных названиях, но суть её одна и та же:
DRAM Over 4G Remapping
H/W DRAM Over 4GB Remapping
H/W Memory Hole Remapping
Hardware Memory Hole
Memory Hole Remapping
Memory Remapping Feature

Зап*ло в том, что в современных ноутбуках, Remap memory залочен в on, но опционально наружу не выведен.
Т.о. из-за этой падляны, на совеменных ноутбуках в 32-ух битах доступно только около 2.5 гига.

Фишка тут вот в чём:
Рукожопые дебилы не могут написать компактный и быстрый код. А их поделкам требуется всё больше и больше памяти. Пользователь временами не хочет переходить на x86_64 системы. Поэтому Remap memory (Memory Remapping Feature) лочится в Enable, чтобы макнуть пользователя в это дерьмо, со всё более и более пухнущими рукожопыми программами. Поэтому пользователь, просто вынужден в добровольно-принудительном порядке переходить на x86_64 системы. Следующая поделка будет жрать ещё больше памяти. Так устроено рубилово бабла. А Линукс или Виндоус, тут уже не играет роли.

[SG]

 Нашёл memory remar где-то в дебрях биоса, задезаблил её. К сожалению, не прибавилось памяти :((

 Вы на ходу добавляете вводные, а я сегодня в биос больше не полезу, завтра.. :))

[Speccyfighter]

Изменение Remap memory в биос на плате с чипсетом p965 работало вот так:
https://arstechnica.com/civis/viewtopic.php?p=5029160&sid=a169b921375ecf8f46b604b75eab7600#p5029160
У меня была P5B-E. Поэтому эту фишку помню.
Вот здесь на скриншоте показан объём памяти когда Remap memory включен на системе с ядром std-def i586:
https://forum.altlinux.org/index.php?topic=30102.msg212997#msg212997

Но мой UEFI BIOS на H61M-PRO предупреждает:
ремапить буду на памяти выше 4Гб.
Поэтому на std-def i586, доступная память глухо сидит на 3498 Mb вне зависимости от состояния опции.
Такие дела...

Тут сложный вопрос, оставаться на более стабильных (имхо) 32-ух битах с pae, но с ограниением на процесс в 2Gb или переходить на x86_64. nVidia например прекратила сборку драйверов 32 bit.

[klark973]

64-бит ест памяти побольше, заметно. Она эти 4 гига съест как 32-х-доступные 2Гб.

Объективное сравнение не помешало бы. И конечно же разница будет не в два раза. В два раза больше места занимают только адреса, это часть некоторых структур данных.

А с ПАЕ видео на полном экране теряет качество, до и нет лайва с ПАЕ.

Мало того, ядра с PAE никто не тестирует и почти никто уже не использует. Они собираются автоматом и присутствуют постольку-поскольку. Так что ничего удивительного.

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

Да, раньше наши гении умудрялись в 64Кб уложить игру в шахматы на ассемблере, я тоже когда-то считал байты на i486, чтобы цикл влезал в кэш. Но такая разработка давно неэффективна, поскольку оптимизирующая компиляция позволяет добиться местами даже большего с меньшими затратами усилий на разработку. Впрочем, на простых примерах после выхлопа gcc -S это утверждение может показаться ложным.

Пользователь временами не хочет переходить на x86_64 системы.

И совершенно зря. Во многих дистрибутивах i586 давно перешла в разряд не основных поддерживаемых архитектур, а многие апстримы на неё попросту забили либо активно это делают. Причины совершенно очевидны: инструмент разработчика -- сборочная машина или сборочный сервер должен быть современным, быстрым и иметь много оперативки. 32-бит машинам этого не грозит. Их удел сейчас -- самые удешевлённые нетбуки и что-то вроде того. Не на чем нативно собирать и тестировать, да и мало кто будет это использовать и тестировать вообще.

В некоторых случаях всё чаще упираемся в верхний предел памяти -- линкёру не хватает ресурсов для воспроизводимой сборки таких приложений, как LibreOffice и Chromium. Всё чаще пакеты i586 будет попадать под правила ExclusiveArch, в Альте за неё будут держаться до последнего, просто из-за накопленной у госзаказчиков старой техники и требований работать как на 64-бит, так и на 32-бит. Но надо понимать, что жизненный цикл архитектуры подходит к стадии микроконтроллеров, дорога в настольные системы ей будет постепенно закрываться.

[SG]

 Speccyfighter, спасибо за участие, жаль, что не прокатило. Отключение "Мемори ремап" не помогло, других указанных пунктоа в БИОСе не нашёл. Ну, да ладно. Давно знаю, что рано или поздно, а придётся переходить на 64, наверное, этот момент сейчас и подошёл.

[Speccyfighter]

Пользователь временами не хочет переходить на x86_64 системы.

И совершенно зря. Во многих дистрибутивах i586 давно перешла в разряд не основных поддерживаемых архитектур, а многие апстримы на неё попросту забили либо активно это делают.

Апстрим это про федору с рэдхатами? Тоже мне апстрим из под лаптя.

А Слака поклала болт на апстрим,

Код: [Выделить]

root@darkstar:~# uname -rm
4.19.16 i686
root@darkstar:~#
root@darkstar:~# sed -n '67,68p; 102p; 181p; 405,406p' /var/log/Xorg.0.log
[    54.870] (II) LoadModule: "intel"
[    54.871] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[    55.221] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20180719
[    56.466] (II) intel(0): switch to mode 1366x768@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none
[    57.277] (II) intel(0): Printing DDC gathered Modelines:
[    57.277] (II) intel(0): Modeline "1366x768"x0.0   76.32  1366 1414 1446 1610  768 771 776 790 -hsync -vsync (47.4 kHz eP)
поэтому она, а это именно нестабильная, просто работает.
Даже стабильный альт может позавидовать стабильности нестабильной слаки.

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

Да пользователю просто насрать и на линкеры и на компилляторы. Ему нужно шоб работало, а не "полный треш после обновления системы".

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

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

Мало того, ядра с PAE никто не тестирует и почти никто уже не использует.

У меня жена экспроприировала мой десктоп на p7 с pae.
Кларк, знаешь когда я к нему подхожу?, - никогда. Ну разве что если сервис tde даст сбой после долгого аптайма, снесёт все значки и сломает выключение и суспенд. И тогда надо подойти и грохнуть процесс startkde. Но на этом и всё.

[asy]

А Слака поклала болт на апстрим,

Увы, но рулят сейчас Либреофисы, которые полноценно на x32 не живут.

[Speccyfighter]

А Слака поклала болт на апстрим,

Увы, но рулят сейчас Либреофисы, которые полноценно на x32 не живут.

Это проблема не архитектуры.
Это проблема писателей либреофиса.
По запросу memory usage, багтрекер либры показал 79 багов, из которых 67 новых и не закрытых.

[asy]

Это проблема не архитектуры.

Проблема архитектуры в том, что ей не уделяют внимания.

[dango]

Проблема архитектуры в том, что ей не уделяют внимания.

А за этой архитектурой - ее пользователи.
В конечном итоге, проблема пользователей в том, что на них не обращают внимание.

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

[Speccyfighter]

А Слака поклала болт на апстрим,

Увы, но рулят сейчас Либреофисы, которые полноценно на x32 не живут.

Это проблема не архитектуры.

Проблема архитектуры в том, что ей не уделяют внимания.

Чтобы офис жрал память как топовые игры под виндой? У них там что, совсем башню переклинило?

Даже Спектрум при памяти прямого достура 41 кило, под is-dos мог работать с текстовыми файлами до 4 Mb. И гиг памяти ему был не нужен. Чтобы положить эти 4 метра на винчестер, нужен был контроллер Nemo.  А про электронный винчестер (который спустя лет 10 на ibm pc назовут флешкой) на Спектруме заговорили в 94-ом году. Привет настоящему из прошлого.
А теперь в Линукс офису 3-ёх (с pae 3.8) гигабайт мало?

[Speccyfighter]

Я эту херь до сих пор инноваторам простить не могу.
Тогда сидел на nForce2 (Socket 462) два канала памяти и с Thoroughbred B. Гнались Табуретки Б как бешеные без тюнинга по напряжению. Плюс были болиды Barton и Thorton с порезаным кешем, но у нас они разметались как горячие пирожки. AMD выпускает плату 64 бит с одноканальной памятью. Пользователь сидя на Бартон упорно не хочет переходить на 64 бит, менять двухканальную память на инновационную одноканальную и сливать стопку баксов. Тогда AMD прекращает выпуск процессоров Socket 462. Юзер послал нахер AMD и повалил на Intel. Чтобы чем-то заткнуть эту засаду и как-то удержать своего пользователя и покупателя, AMD выпускает это говнище Sempron под Socket 462.
Моё терпение в конце-концов тоже лопнуло: идите вы нахер с вашими инновациями.

А прекратят альты выпускать 32 бит, ну и хрен с ним. У Патрика в huge-smp PAE включено. В current ядро 4.19, а значит засада с RTC SRAM в ядре закрыта. Там в свежем каррент у Эрика нужно только выбрать другой кастом из трёх штук нужный в /etc/profile.d/man-db.sh. Но лучше бы это Эрику подсказать, чтобы дефолт сменил. Всё остальное в 32-ух битах просто работает. И если мне не изменяет память, в Salix вообще два ядра в образе, - huge и huge-smp с pae.