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

Это какое-то враньё.

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

Будьте пожалуйста снисходительны - один человек не может знать всё и попробовать всё.

Знания уже все предоставлены.

Я вон тоже верю «где-то услышанным» рассуждениям о ресурсе и износе ssd хотя лично у меня еще ни один ssd не сдох.

У меня тоже SSD жили более 10 лет пока я их не выкинул, хотя раньше активно использовал swap на них, никак не щадил. Таким даже не интересовался, для меня это расходник.

а обоснованно предполагаю исходя из цифр задействования свопа.

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

Не достижением,а более оптимальным режимом работы

Нет, оптимальным оно не станет, сколько не повторяй.

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

Куда он вырастет?..

Ну вот допустим, у кого-то 256 ГБ памяти. Свап 4 гига. 1 гиг свапа занят, 3 пустуют. Программами занято 9 ГБ оперативы. Остальное кэшем. Ему ТОЧНО надо ещё планок докупить, чтобы свап отключить и сделать watchcat382 счастливым? Или может хрен с ним с watchcat382, и можно не третить деньги, оставить свап и пользоваться дальше? Такой вот вопрос в лоб, а то мы всё вокру да около.

допустим, у кого-то 256 ГБ памяти. Свап 4 гига

🤦

Делай 4 кб тогда уже.

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

А потом станет анахронизмом и деление на «память» и «диск». Имея огромное адресное пространство проца - почему бы не отобразить флэш-память туда? А то флэшке которая BIOS это можно,а флэшкам которые «диск» - почему-то нельзя. Кстати, всякие микроконтроллерные варианты линуксового ядра уже давно умеют execute in place,то есть без копирования кода в озу,запуск прямо оттуда где лежит. Зачем производить привязку адресов при каждом запуске программы? Можно делать это один раз при ее инсталляции в [постоянную] память.

Для этого нужно энергонезависимую память подтянуть по скорости, но думаю это будущее действительно. Удивительно что Multics из 60х к такой модели был приспособлен, а Linux сейчас не особо.

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

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

Есть подозрения что и у встроенного wifi радиочастотные характеристики сильно хуже моей Alfa AWUS 036H,которой я в экспериментах успешно «простреливал» поперёк пролив Бьерке-Зунд,на берегу которого и живу. Причем не сказать чтобы особо сильно монстрообразные антенны были.

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

Тут ничего не могу сказать - пока что с такими процами экспериментировать не довелось и нужность их для моих целей оценить не могу. Вон в моноблоке Асус стоит проц i5-8250U,так у него и так в режиме чтения форумов и почтовой переписки энергопотребление (всей платы куда он впаян) всего около полутора десятков ватт. Меньше может быть нужно только в девайсах с батарейным питанием,но уж точно не в десктопах.

Современные Intel процессоры выше i3 все с E ядрами. На десктопе они не для снижения потребления, а для многопоточных нагрузок, по скорости они при этом почти на уровне ядер i9-10850k который был P-only. Мерил своими специфичными «бенчмарками».

$ nproc
32 = 8(x2)P+16E

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

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

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

В общем случае - кэш должен «знать» что кэширует и делать это наиболее оптимально именно для каждого случая применения. Именно отсюда рекомендация для СУБД предпочитать их собственное кэширование а не системное которое об индексах ничего не знает и реализует какой-нибудь из самых простых и от того наиболее универсальных алгоритмов. Но эта универсальность - в ущерб эффективности на каждом конкретном применении.

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

А я его в ОЗУ и засунул,в tmpfs. Как ни странно - субъективная отзывчивать браузера стала немного лучше чем с большим кэшом на диске,который со временем забивается содержимым единожды посещенных и не нужных в будущем сайтов. Да, при первом входе на сайт загружается чуть больше контента, а на следующих страницах работает быстрее потому как не нужно искать в большом кэше только что загруженное. Ну и вообще пропали ситуации когда какой-нибудь элемент подгрузился из кэша в то время когда должен был перечитаться с сайта. Если что-то должно,а не прочиталось - то это сразу видно и можно «пнуть» принудительно. Какого-то фатального увеличения расхода трафика тоже не заметил. Как расходовалось за месяц 3-4 гига так и осталось. Напомню,что к киноискусству я равнодушен также как большинство людей к симфонической музыке - это чтобы не удивлялись столь небольшим цифрам. А технические форумы куда я обычно хожу - жрут мало.

SSD жили более 10 лет пока я их не выкинул

Не понял зачем выкидывать SSD если они исправны? Или они всё-таки как-то дерградируют? Скорость например падает?

А зачем мне такие медленные диски? У SATA SSD максимальная скорость чтения близка к 500 мб/сек, у моего текущего диска скорость записи больше 10 гб/сек.

чьё использование компьютера явно отличается от среднелоровского.

Ну тут собрались люди,которые активно используют компы для самых разных задач. Так что говорить о каком-то усреднении применительно именно к обитателям лора - на мой взгляд не совсем корректно. Это для «нетехнического» бытового юзера еще можно какой-то усредненный портрет составить. А как усреднять например меня с моим использованием компа для изготовления микроконтроллерных любительских поделок и кого-нибудь из присутствующих тут профессиональных программистов,пишущих мегабайты кода и использующих монстрообразные профессиональные IDE,написанные на жручей джаве? Вот уж точно - получится средняя температура по больнице с учетом морга.

Ну вот допустим, у кого-то 256 ГБ памяти. Свап 4 гига. 1 гиг свапа занят

А такую ситуацию вообще реально создать без ручного кручения настроек? Чтобы при 256 ГБ памяти и занятости программами всего 9 Гб система еще и в свап полезла,да еще целый гигабайт там заняла? Как-то я не представляю что надо делать на десктопе (не высоконагруженном сервере) чтобы так получилось. Да и десктопы с 256 Гб памяти встречаются весьма не часто.

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

Будь например у меня комп,поддерживающий столько памяти,я бы попробовал настройки как у некоторых live-дистрибутивов - где вообще всё работает в ОЗУ,а в конце сеанса состояние и измененные файлы сохраняется на диск. (нет,я не разбирался как именно там это сделано,просто читал о таких сборках линукса,по-моему у Альта такая была если не путаю)

Где-то в документации у редхата видел совет при объемах памяти 128+ делать свап на 4-6 гигов. Но это для серверов была рекомендация. Может там какая-нибудь монстрообразная высоконагруженная СУБД крутится которая и столько памяти выржать может.

У этого совета могут быть ровно две причины:

1) обход каких-то линуксовых багов (ядро, что бы кто ни говорил, не особо рассчитано на работу без свапа вообще, даже если памяти хватает с избытком)

2) идиотизм автора данной документации

Может там какая-нибудь монстрообразная высоконагруженная СУБД крутится которая и столько памяти выржать может.

Если она сожрала 128 то ещё 4-6 погоды точно не сделают.

Для этого нужно энергонезависимую память подтянуть по скорости

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

Удивительно что Multics из 60х к такой модели был приспособлен

Спасибо, не знал об этом. А так-то даже первые IBM PC могли исполнять код бейсик-интерпретатора из ПЗУ. При этом с дискеты в ОЗУ грузилась только программа на этом бейсике,которая для него фактически являлась данными с которыми он работал. Также в адресное пространство проца отображались картриджи на бездисковых игровых приставках и программы исполнялись прямо «из картриджа».

а Linux сейчас не особо.

Как я уже говорил, execute in place вполне умеют микроконтроллерные варианты линукса.

Шина PCIe умеет предоставлять воткнутым в нее устройствам окно в адресном пространстве (максимальный размер не знаю,не интересовался). «Диски» в виде втыкаемой в слот платы с микросхемами флэш-памяти существуют,правда тоже не знаю максимальный размер окна которым они способны отобразиться в память. Но явно в обоих случаях не маленький. Так что рабочий прототип компа с такой конфигруацией памяти можно создать уже сейчас. Самое сложное будет это добыть подробную документацию на системную плату чтобы разобраться как рулить всем этим отображением адресов. Вот кстати человек возился с адресами отображения памяти. Увы - методом тыка,без нормальной документации: https://habr.com/ru/articles/449940/

А дальше вопрос лишь в том,кто первый сделает под это свой чипсет чтобы память не через шину PCIe подключать(чтобы побыстрее). Хотя вон например на видеокартах есть свой BIOS(всё та же флэш-память),отображаемый в адресное пространство именно что через шину. И скорость его исполнения никого особо не смущает - значит не настолько уж маленькая.

Современные Intel процессоры выше i3 все с E ядрами.

Ну вот у этого моего проца i5-8250U название начинается с i5 - у него что,тоже разнотипные ядра есть? nproc выдает просто 8. Сомнительно как-то.

От 13 поколения и далее %) У меня nproc 32 выдает просто, расшифровку я сам добавил 8P ядер которые дают 16 потоков за счет HT, и 16 ядер E.

А зачем мне такие медленные диски?

Как обычно - что-нибудь хранить. Для работы - быстрый диск,для хранения и относительно медленные сойдут. Тем более что ssd в бездействии шпинделями не крутят и электричество не жрут.

Я кстати хотел бы поэкспериментировать с nvme ssd,даже карточку-переходник с M.2 на PCE-E добыл. Но вот как выбрать диск,совместимый с этой карточкой и моей системной платой - понятия не имею. Так пока и лежит. Тащить системный блок куда-то в мастерскую и там подбирать - не вариант,слишком далеко. А если куплю через кого-то то уже не вернуть будет если не заработает - никто не согласится заморачиваться с процедурой возврата ибо это куда более геморройно чем просто купить.

Как обычно - что-нибудь хранить. Для работы - быстрый диск,для хранения и относительно медленные сойдут.

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

Но вот как выбрать диск,совместимый с этой карточкой и моей системной платой

Дать ссылки на то и другое, подскажем.

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

Супер. 64 терабайта полностью перекрывающихся 4 гигабайтных сегментов :)

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

Господа, на такой элементарный вопрос уже 723 сообщения. Может я что-то пропустил? Можно tl;dr, наверное сейчас как-то по другому разбивают? Уже появилось что-то лучше /boot, lvm+luks=/,/home?

В свежеустановленной виртуалке с 32 битным дебианом сразу после загрузки free 3.7 гигабайт, а avaible — 3.5. Хотя в нормальной система avaible должен быть больше free. Этот хвост в 200 мегабайт может быть использован для свапа (сейчас там компилируется ядро, в свапе 15 мегабайт). Но полноценной работой виртуальной памяти это назвать сложно

Мы тут уже давно про свап и адресацию памяти в i386 сремся, велкам :)

lvm+luks=/,/home?

btrfs+luks+btrfs subvolumes, конечно же

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

Твои бутафорные полностью перекрывающиеся 64 терабайтные сегменты никому не интересны. Размер линейного виртуального адресного пространства, в которое отображаются сегменты — 4 гигабайта.

А такую ситуацию вообще реально создать без ручного кручения настроек? Чтобы при 256 ГБ памяти и занятости программами всего 9 Гб система еще и в свап полезла,да еще целый гигабайт там заняла?

Какая разница, сколько занимает резидентная память + анонимная память процессов, если кроме этого еще есть дисковый кеш и free, которую система старается держать ненулевой (хотя бы пара сотен мегабайт там должно быть)?

У сегментов тоже есть бит отсутствия, так что совсем не обязательно перекрывающихся. Хотя, если они будут прямо 4гб каждый, то да, будет неудобно их постоянно переключать. Практически удобное использование начинается когда в 4гб окно одновременно хотя бы 10 сегментов влезают, что соответствует общему постранству в примерно 6тб.

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

И ещё раз повторю: процессорные сущности свап не адресуют. Для страниц/сегментов в свапе установлен флажок «отсутствия», а все выяснения местонахождения этого куска данных на диске делаются в коде ОС, где ты можешь внутренне использовать хоть 256-битную адресацию.

Уже появилось что-то лучше /boot, lvm+luks=/,/home?

Да. /boot как отдельный раздел это устаревшая практика из начала 90-х, он уже давно просто директория в корне. А lvm просто не нужен. /var и /tmp надо отдельные.

ты забыл про /boot/efi :)

Похоже, я начинаю понимать. Ты предлагаешь поочередно отображать разные сегменты в линейное 32 битное пространство. При этом сегмент может быть как в памяти, так и в свапе. Это, конечно, лютый костыль и производительность там будет аховая, но формально я был неправ, да. Непонятно, правда, реализовано ли это в современных операционных системах (винда, линукс, *BSD). Лично я в этом сильно сомневаюсь по причинам, изложенным выше

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

А вот если это применять для маппинга физических >4гб в виртуальные >4гб через страничное <4гб окно то да, думаю проседание будет заметным по сравнению с прямым отображением (когда всё везде влезает), по сути это будет тоже свап, но не дисковый, а целиком в памяти. Хотя копировать память не придётся (все операции - в таблицах), но на каждое переключение отображение получается скрытый «сисколл» (вызов ядра), а они занимают много времени. Если программа не часто переключает сегменты, может и не заметно будет.

Непонятно, правда, реализовано ли это в современных операционных системах (винда, линукс, *BSD). Лично я в этом сильно сомневаюсь по причинам, изложенным выше

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

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

А вот если это применять для маппинга физических >4гб в виртуальные >4гб через страничное <4гб окно то да, думаю проседание будет заметным по сравнению с прямым отображением (когда всё везде влезает), по сути это будет тоже свап, но не дисковый, а целиком в памяти. Хотя копировать память не придётся (все операции - в таблицах), но на каждое переключение отображение получается скрытый «сисколл» (вызов ядра), а они занимают много времени. Если программа не часто переключает сегменты, может и не заметно будет.

Учитывая, что сейчас дисковый кеш в системе, которая, в общем-то, ничем серьезным в текущий момент не занимается, может составлять те самые 4 гигабайта и больше, переключатся придется часто. В ту же степь идут интерпретаторы и языки на основе виртуальной машины (исполняемый код в таком случае — анонимная память, и кода может быть много). А вместе с интерпретируемым джаваскриптом туда же идет и среднестатистический браузер, например. А еще процессы могут мапить файлы непосредственно в свое адресное пространство. С учетом того, что уже Pentium Pro позволял строить многопроцессорные системы, вполне может сложится ситуация, в которой двум работающим одновременно процессам понадобятся два разных сегмента. Получаем ненужные блокировки и снижение эффективности SMP. Получается, что овчинка выделки не стоит. Либо процессу достаточно 4 гигабайт, либо будут адские тормоза, вызванные сочетанием PAE и переключением сегментов.

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

Тогда я фактически был прав, когда сказал, что наличие в 32 битной системе 4 гигабайт физической памяти делает свап практически бесполезным. И мы возвращаемся к рассуждениям watchcat382 о том, что у него никогда не используется свап.

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

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

В ту же степь идут интерпретаторы и языки на основе виртуальной машины (исполняемый код в таком случае — анонимная память, и кода может быть много)

Ну не гигабайты же. Думаю что речь всё-таки про данные.

которой двум работающим одновременно процессам понадобятся два разных сегмента

Сегменты это внутреннее дело процесса, и конечно они у всех разные. Это ничему не мешает.

Тогда я фактически был прав, когда сказал, что наличие в 32 битной системе 4 гигабайт физической памяти делает свап практически бесполезным

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

Вот примерная (условная и упрощённая, но суть передаёт) схема работы страничной виртуальной памяти на 32-битной системе с PAE:

struct process {
  ptr64 pages[1048576];
};

// этот массив хранится напрямую в физической памяти, на самом деле он конечно выделяется динамически а не хранится для всех возможных pid-ов
struct process processes[MAX_PID];

ptr32 p = 0x12345678;
x = *(char*)p;

p64 = processes[getpid()].pages[p >> 12]; // p>>12 это 0x12345-й элемент массива
// ^ чтобы тут не лазить каждый раз в память, в проце есть специальный кеш, это не тот кеш который L1 L2 L3 а отдельный; он свой у каждого ядра и у каждого гипертрединг-потока, сбрасывается ядром при переключении процесса, либо в нём сбрасываются ядром отдельные записи когда надо подправить таблицу pages[]

if(p64 & FLAG_MISSING) {
  raise_page_fault_exception();  // вызов ОС - страницы нет в физ. памяти, назад уже не вернёмся
  // ОС либо сегфолтнет процесс, если страницы этой вобще нет и не предполагалсь,
  // либо аллоцирует в физ. памяти новую пустую страницу, если это первое обращение к блоку после юзерспейсной аллокации (оверкоммит)
  // либо прочитает её из свапа, если она в свапе
  // после этого ОС вернёт управление процессу на то же место чтоб он попробовал прочитать ещё раз заново
}
if(!(p64 & FLAG_ALLOW_USERSPACE)) {
  raise_page_fault_exception(); // вызов ОС - процесс хочет нарушить права доступа, назад уже не вернёмся
}
p64 = (p64 & 0xFFFFFF000) | (p & 0x0FFF); 
// ^ в младших 12 битах p64 - флаги, старшие 28 бит зарезервированы
// младшие биты берём из p, там 0x678
x = *(char*)p64;

Кстати, если PAE выключен, то отличие будет только такое: таблица pages станет 32-битной, и p64 тоже станет 32-битным (назовём p32), вся логика остаётся как была.

/boot как отдельный раздел это устаревшая практика из начала 90-х, он уже давно просто директория в корне.

А если плата только UEFI умеет? Ему же вроде как нужен отдельный раздел с FAT на диске,где оно свои «запчасти» держит? Мне пока uefi-only платы не попадались так что не экспериментировал.

И мы возвращаемся к рассуждениям watchcat382 о том, что у него никогда не используется свап.

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

Либо процессу достаточно 4 гигабайт

Если это среднетипичный десктоп то там не часто найдутся процессы которым недостаточно 4 гигабайт.

либо будут адские тормоза

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

Тогда эту бракованную плату надо сдать назад в магазин (или в помойку) и взять нормальную.

Если это среднетипичный десктоп то там не часто найдутся процессы которым недостаточно 4 гигабайт.

«среднетипичный десктоп» в 2022 имхо это использующий вэбню. Так вот на основании чего вы решили, что вэбне достаточно 4ГБ ?

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

А вот это абсолютно верно и неверно одновременно если бы вы не упомянули кэш.

Это какие сайты потребляют более 2 гб памяти? А более 1 гб?

Это какие сайты потребляют более 2 гб памяти? А более 1 гб?

Вы по одной страничке открываете?

дебилом быть незапрещнно.

По одной вкладке за раз смотрю, да. В Firefox и Chrome фоновые вкладки выгружаются из памяти.

По одной вкладке за раз смотрю

Вопросов нет.

«среднетипичный десктоп» в 2022 имхо это использующий вэбню.

«вэбня» это что? Если обычное лазание по сайтам - то да,согласен. Если какие-нибудь например биржевые терминалы,написанные на джаве и запускаемые внутри браузера - то это не самое типичное применение. Видел когда-то такое в офисе одного информагентства. И да,ресурсы оно сильно кушало.

на основании чего вы решили, что вэбне достаточно 4ГБ ?

Вот прямо только что два часа просидел на forumhouse.ru с моноблока Асус,у которого всего 4 Гб памяти. Никаких тормозов и насилования диска не наблюдал. Браузер Vivaldi. Хотя конечно я читал здесь на Лоре про каких-то странных людей,которые открывают в браузере открывают аж сотни вкладок. Не представляю зачем и как они в этой мешанине не путаются. Я больше примерно десятка вкладок не использую - не потому что комп не может,а потому что мне неудобно. Сейчас вот четыре открыто здесь на Лоре.

 free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       774Mi       1.8Gi       209Mi       1.2Gi       2.5Gi
Swap:          3.9Gi          0B       3.9Gi

В Firefox и Chrome фоновые вкладки выгружаются из памяти.

В Vivaldi похоже что тоже. В этом есть ровно один очень незначительный недостаток - если включить какое-нибудь «интернет-радио» то при переключении на другую вкладку музыка выключается. Поэтом музыку слушаю через отдельный плейер,умеющий и потоки из интернета воспроизводить.