LINUX.ORG.RU
ФорумAdmin

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

 


0

4

Давно прошли те времена, когда диск скрупулезно разбивали на 4 раздела -
/boot, /root, /home и даже /var.

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

Сейчас хочу рационально разбить SSD диск сравнительно небольшой емкости в 256 ГБ.

Swap обязательно оставлю. мало ли что.
Root и Home помещу в один раздел.

А вот что делать с Boot - быть или не быть?

Если быть, то какую ФС лучше выбрать?
Потому что заметил, что на всяких там Raspbian и т.п. выбирают даже старинную FAT32.

С чем связан такой выбор - увеличивает скорость загрузки или что?

★★★★★

Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от hateWin

А я хочу, чтобы ты объяснил

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

И похоже что меня тут неправильно поняли. Я не призывал отказаться от свапа,я призывал отказаться от отдельного РАЗДЕЛА для свапа(использовать файл вместо этого).

watchcat382
()
Ответ на: комментарий от watchcat382

И похоже что меня тут неправильно поняли. Я не призывал отказаться от свапа,я призывал отказаться от отдельного РАЗДЕЛА

Ты пытался всем доказать, что использование системой свапа — повод докупить памяти, а при достаточном количестве памяти своп ненужен. Как так получается, что при достаточном количестве памяти свап все равно используется?

hateWin ★☆
()
Ответ на: комментарий от watchcat382

Дистанционно исследовать что происходит на вашем компе я не могу

Я тебе вывод free -h показал. Недостаточно?

Почти всегда нулевое использование свапа при его наличии

Это если котиков смотреть.

hateWin ★☆
()
Ответ на: комментарий от hateWin

Ты пытался всем доказать, что использование системой свапа — повод докупить памяти

Да, это так,учитывая копеечную цену памяти сегодня.

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

Я не знаю почему так на вашей машине получается. Я тоже несколько раз показывал вывод free и у меня свап нулевой. Хотя если на том из двух моих компов где памяти меньше начать делать что-нибудь для него не слишком подходящее(просто потому что было Лень включать большой комп) - то свап будет использоваться в незначительных количествах.

watchcat382
()
Ответ на: комментарий от hateWin

Почти всегда нулевое использование свапа при его наличии

Это если котиков смотреть.

Я вот тоже удивляюсь что делают люди что у них браузер какие-то дикие гигабайты памяти отъедает. Читал сейчас новости на РБК, даже несколько вкладок использовал. Свап нулевой. Браузер Vivaldi. А так я и схемы в KiCAD рисую (радиолюбительского уровня) и код для микроконтроллеров пишу в текстовом редакторе (не ide) и компилирую gcc, и даже картинки с «морально устаревшего» Canon 1100D слегка обрабатываю в gimp. Свап тоже обычно нулевой или в крайнем случае околонулевой. Так на этом компе (asus моноблок) вообще только четыре гига памяти. Он у меня для тех задач где производительность ограничивается моими мозгами,а не компа. Зато электричества мало кушает. На «большом» компе 16G и там я вообще не помню чтобы использование свапа видел. Может конечно и было,но настолько редко и незначительно что я не заметил. Ну нет у меня дома таких задач чтобы 16 гигов выжрать.

watchcat382
()
Ответ на: комментарий от watchcat382

Да, это так,учитывая копеечную цену памяти сегодня

Твою ж налево, у тебя перед глазами данные, доказывающие обратное. Система использует свап, даже когда приложения занимают 6 гигабайт из 16, а доступно еще 8 гигабайт. О каком недостатке памяти идет речь?

Я не знаю почему так на вашей машине получается

А я знаю. Потому, что люди, рассуждающие о том, что свап нужен только нищебродам, не понимают, как работает выделение памяти в линуксе (и не только).

hateWin ★☆
()
Ответ на: комментарий от watchcat382

Браузер Vivaldi. А так я и схемы в KiCAD рисую (радиолюбительского уровня) и код для микроконтроллеров пишу в текстовом редакторе (не ide) и компилирую gcc, и даже картинки с «морально устаревшего» Canon 1100D слегка обрабатываю в gimp

Значит, ничего серьезного ты там не делаешь. Меня не интересует, что происходит, пока у тебя открыто от силы пять вкладок в вивалди и одна картинка в гимпе. Меня интересует тот факт, что как только free подойдет к концу (в моем случае это нексолько сотен мегабайт при объеме памяти 16 гигабайт), система начнет либо вытеснять анонимные страницы в свап, либо сбрасывать дисковый кеш. И при грамотной настройке свапа можно добится сохранения ценного кеша в памяти, увеличив тем самым производительность системы.

hateWin ★☆
()
Ответ на: комментарий от watchcat382

Ну нет у меня дома таких задач чтобы 16 гигов выжрать

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

hateWin ★☆
()
Ответ на: комментарий от hateWin

как работает выделение памяти в линуксе

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

Система использует свап, даже когда приложения занимают 6 гигабайт из 16, а доступно еще 8 гигабайт.

Это говорит о неоптимальности настроек у тех,у кого так происходит. Если вы утверждаете что поняли как работает выделение памяти - можете объяснить какой смысл вытеснять в свап несколько сотен мегов когда доступно восемь пустых гигабайтов ОЗУ,за которое вы уже заплатили?

А также напомню,что эта тема началась с разбивки ДИСКА. Опять же возникает вопрос - какой смысл делать отдельный РАЗДЕЛ когда можно сделать свап-ФАЙЛ? Да еще и создавать его по необходимости автоматически. И также напомню,что я возражал именно против раздела,а не свапа вообще - это мне уже позже приписали.

watchcat382
()
Ответ на: комментарий от hateWin

Меня интересует тот факт, что как только free подойдет к концу (в моем случае это нексолько сотен мегабайт при объеме памяти 16 гигабайт), система начнет либо вытеснять анонимные страницы в свап, либо сбрасывать дисковый кеш. И при грамотной настройке свапа можно добится сохранения ценного кеша в памяти

И тут я с вами полностью согласен! Именно про несколько сотен оставшихся мегабайтов и только ПОСЛЕ этого использование свапа. Но у вас почему-то свап начинает использоваться при восьми свободных гигах ОЗУ. Этому есть рациональное объяснение?

watchcat382
()
Ответ на: комментарий от anonymous

Это да. Я когда-то скачивал с википедии огромную фоторепродукцию вавилонской мозаики. В целом, она кое-как редактировалась, но инструмент «выделение переднего плана» часто приводил к краху гимпа

hateWin ★☆
()
Ответ на: комментарий от watchcat382

У меня оно почему-то работает по-другому. И нет,я вообще ничего в настройках свапа не крутил

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

Я кстати НЕ отказался

Что не мешает тебе пороть чушь

Это говорит о неоптимальности настроек у тех,у кого так происходит

Докажи.

Если вы утверждаете что поняли как работает выделение памяти - можете объяснить какой смысл вытеснять в свап несколько сотен мегов когда доступно восемь пустых гигабайтов ОЗУ,за которое вы уже заплатили?

пустых

Вот пока ты будешь называть страницы, которые отображаются в колонке avaible пустыми, ты и дальше будешь молоть феерическую *уергу про свап. Осиль разницу между free и avaible и не позорься

А также напомню,что эта тема началась с разбивки ДИСКА. Опять же возникает вопрос - какой смысл делать отдельный РАЗДЕЛ

Я нигде не настаивал на том, что нужно делать раздел. Я сказал, что свап нужен. Желатьельно в виде zswap. У меня сейчас свап создан средствами btrfs, чтобы не усложнять разметку. Сути это не меняет

hateWin ★☆
()
Ответ на: комментарий от watchcat382

Но у вас почему-то свап начинает использоваться при восьми свободных гигах ОЗУ

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

hateWin ★☆
()
Ответ на: комментарий от hateWin

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

Память может быть занята или программами или кэшом или таки быть вообще пустой. Вообще пустой в линуксе как правило нет - он их кэшем заполняет (не сразу). Если у вас программы заняли 8 гигов - вы уверены что вам нужно еще аж 8 гигов кэша и при этом часть страниц с программами складывать в свап? Если да и действительно нужен такой огромный кэш то вопросов нет. Ну кроме как к несколько невежливому типично «учительскому» тону. Я так тоже могу потому что линукс использую с 1996 года :)

Я нигде не настаивал на том, что нужно делать раздел.

Ну так и о чем мы тогда спорим в рамках темы о РАЗБИВКЕ ДИСКА? У вас есть свап,у меня тоже есть свап но без отдельного раздела, и я поставил столько памяти что на моих задачах он типично пустой. Были бы у меня задачи,приводящие к интенсивному обмену со свап-файлом на моих компах - добавил бы еще памяти ибо стоит она нынче как один поход за продуктами,а вот время хорошо экономит. По моим наблюдениям,системы которые интенсивно используют свап - субьективно выглядят тормозными.

Желатьельно в виде zswap.

А чем это лучше обычного свапа? Особенно в вашей и моей ситуации,когда свап используется мало. Вот если бы обмен со свапом был интенсивный как например в виндах при малом количестве памяти - то тогда да,согласен, имело бы смысл пытаться его ускорять(насколько я понимаю zswap пытается делать именно это).

watchcat382
()
Ответ на: комментарий от CrX

По нынешним временам это наоборот мелкий.

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

watchcat382
()
Ответ на: комментарий от watchcat382

Запуск тяжелого IDE на джаве и компиляция какого-нибудь огромного проекта в десятки раз больше чем линуксовое ядро?

Как раз для этого именно кэш не требуется.

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

Да много чего. Начиная от банального сидирования торрентов.

CrX ★★★★★
()
Ответ на: комментарий от watchcat382

Память может быть занята или программами или кэшом или таки быть вообще пустой

Ты когда начнешь учить матчасть? То, что помечено как avaible, либо не распределено (free), либо занято чистым кешем.

Вообще пустой в линуксе как правило нет - он их кэшем заполняет

Ты недавно утверждал, что у меня 8 гигабайт ПУСТОЙ памяти. А теперь уже про кеш вспомнил. Прогресс?

Если у вас программы заняли 8 гигов

Программы заняли 6 гигов. То, что непосредственно занято запущенными процессами, отображается в колонке used, а не avaible

вы уверены что вам нужно еще аж 8 гигов кэша и при этом часть страниц с программами складывать в свап?

Я уверен, что система использует lru кеш, чтобы определить редкоиспользуемые страницы памяти. Со временем эти страницы либо вытесняются в свап (анонимные), либо просто обнуляются (чистый кеш). И лучше держать в памяти то, что действительно часто используется, а не мусор.

Ну кроме как к несколько невежливому типично «учительскому» тону

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

Я так тоже могу потому что линукс использую с 1996 года :)

Иногда старость приходит одна

Ну так и о чем мы тогда спорим в рамках темы о РАЗБИВКЕ ДИСКА?

Мы спорим о нужности свапа. Это ты утверждал, что свап не нужен при доступности дешевой памяти.

По моим наблюдениям,системы которые интенсивно используют свап - субьективно выглядят тормозными

Эти же системы при тех же нагрузках вообще стояли бы колом, если бы там не было свапа

hateWin ★☆
()
Ответ на: комментарий от CrX

Начиная от банального сидирования торрентов.

А это что - операция,критичная к скорости? Ну раздает что-то там в фоне и пусть раздает. Тем более торрентокачалке обычно специально зарезают скорость чтобы веб-серфингу не мешала выкушивая весь канал. Так что извините,но надобность для этого восмигигового кэша весьма сомнительна.

watchcat382
()
Ответ на: комментарий от watchcat382

А это что - операция,критичная к скорости?

Причём тут скорость?

Ну раздает что-то там в фоне и пусть раздает.

Если она раздаёт параллельно 5 файлов, каждый по 10 ГБ (или наоборот. Условно, размеры промасштабируй под те, когда станет понятно), и кэша совсем-совсем мало, она при этом постоянно шуршит диском, мешая тем самым другим параллельным операциям чтения/записи на том же самом диске. Чем больше удаётся закэшировать, тем меньше чтений одних и тех же участков приходится повторять из раза в раз, из раза в раз, из раза в раз.

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

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

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 3)
Ответ на: комментарий от hateWin

То, что помечено как avaible, либо не распределено (free), либо занято чистым кешем.

Я именно это и сказал. И удивился зачем вам восьмигиговый кэш.

Ты недавно утверждал, что у меня 8 гигабайт ПУСТОЙ памяти.

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

Программы заняли 6 гигов.

То есть у вас даже не 8,а почти 10 гигов кэша? Нафига?

И лучше держать в памяти то, что действительно часто используется, а не мусор.

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

ты просто несешь чушь

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

уже несколько человек объяснили, зачем нужен свап

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

Это ты утверждал, что свап не нужен при доступности дешевой памяти.

Нет,я утверждал не это. Я утверждал что РАЗДЕЛ свап не нужен на диске,а также что если система пытается активно использовать свап то это повод купить дешевой памяти. И приводил в пример свои компы где система свап почти никогда не использует. Хотя он ЕСТЬ.

Эти же системы при тех же нагрузках вообще стояли бы колом, если бы там не было свапа

Вот потому и говорю что памяти купить надо и диск свапом не мучить(особенно если он ssd как нынче это часто бывает).

watchcat382
()
Ответ на: комментарий от CrX

кэша совсем-совсем мало, она при этом постоянно шуршит диском,

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

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

Давно уже не зарезают

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

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

Это именно если совсем мало. Но 8 гигов это много для раздачи файлов любого мыслимого размера

Это не много, это примерно как раз, а иногда даже маловато. Не знаю, что там у вас за мыслимые размеры, но нынче кино по 10–50 ГБ, AAA-игры 50–150 ГБ, музыка по одному гигу альбом, но её много, и даже какой-нибудь там дефолтный образ Ubuntu 24.04.1 LTS весит 5.8 ГБ. А раздаётся при этом не один, а несколько файлов параллельно, и не одному, а нескольким юзерам.

CrX ★★★★★
()
Ответ на: комментарий от watchcat382

Я именно это и сказал. И удивился зачем вам восьмигиговый кэш

Ты сказал, что у меня 8 гигабайт пустой памяти.

Не придирайтесь к словам. Пустой - это в смысле полезным софтом не занятой

Это не придирка, это принципиальная разница. То, что ты ее не видишь, говорит о том, что ты не понимаешь, о чем говоришь.

То есть у вас даже не 8,а почти 10 гигов кэша? Нафига?

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

Вы уверены что у вас столько именно часто используемых данных,а не один раз прочитанных и в кэше с тех пор болтающихся?

Если бы они были просто болтающимися, их бы в памяти не было. А ядро решило, что дешевле выгрузить редко используемые анонимные страницы, чем сбросить этот кеш. Без кеша пришлось бы дергать диск на каждый чих, и скорость компиляции уперлась бы не в память и процессор, а сраный SATA SSD.

Я же не называю ваше желание держать в памяти на десктопе почти 10 гигов кэша «чушью». Хотя с моей точки зрения оно скажем вежливо более чем странное. Разные мнения и разные взгляды на технические вопросы - это совершенно нормально

У тебя нет «точки зрения по техническому вопросу». У тебя есть каша в голове.

Объяснили зачем - в случае нехватки ОЗУ для решаемых задач

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

Все аргументы крутятся вокруг экономии памяти

Пока память не бесконечная, ее придется экономить. Для тебя это открытие, да?

Вот например когда десять гигов кэша и так есть,а юзеру и этого мало из-за специфики того что он делает

Ты понимаешь, что эффективность решения практически любой задачи, с которой можно столкнуться на десктопе или сервере, выше при наличии свапа, чем при его отсутствии? Нет здесь никакой специфики. Прочитать данные с диска один раз — это лучше, чем постоянно обращаться к диску. Особенно, если эти данные читаются рандомно, а диск — SMR HDD, к примеру. Что здесь для тебя не очевидно?

Так вот я говорю что в таких случаях лучше бы памяти добавить чтобы было как у меня

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

Свап нужен только на случай какого-то редкого пикового потребления памяти существенно (в разы) выше обычного для данного пользователя и его задач.

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

Нет,я утверждал не это

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

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

Я утверждал что РАЗДЕЛ свап не нужен на диске,а также

На необходимости делать именно раздел, а не файл, никто не настаивал. Твои оппоненты спорят именно с этим утверждением:

если система пытается активно использовать свап то это повод купить дешевой памяти

Почему ты все время соскакиваешь на тему «swap раздел vs swap файл»? На эту тему с тобой никто не спорит.

И приводил в пример свои компы где система свап почти никогда не использует. Хотя он ЕСТЬ

Значит, на этих системах смотрят котиков.

и диск свапом не мучить

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

особенно если он ssd как нынче это часто бывает

Свап никак на долговечность ssd не повлияет, если покупать не совсем говно из дефективных SD карточек.

hateWin ★☆
()
Последнее исправление: hateWin (всего исправлений: 3)
Ответ на: комментарий от watchcat382

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

Пытаясь доказать «ненужность свапа в эпоху дешевой памяти», ты готов доказать, что свап позволяет использовать память эффективно, даже если она дешевая? Л — Логика

hateWin ★☆
()
Ответ на: комментарий от watchcat382

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

Уменьшение пропускной способности канала увеличит конкуренцию между пирами за скорость этого самого канала. Твой диск они от этого дрючить не перестанут.

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

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

hateWin ★☆
()
Ответ на: комментарий от hateWin

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

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

Ты предлагаешь просто выбрасывать деньги на ветер, покупая память

Вы застряли где-то в 90х-00 годах когда память стоила дорого. Сейчас 16 гигов памяти(обычной,не экзотики какой-то) стоят как пара походов в магазин за едой. Если для вас это «выбрасывать деньги» то ваша финансовая состоятельность вызывает сомнения.

утверждал, что лучше не использовать свап

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

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

16 гигов это для вас «непомерное количество»? Вы точно не из двухтысячных годов пишете? Я же не 128+ гигов ставить предлагаю. Хотя многие из тех,для кого комп является основным рабочим инструментом, уже ставят,особенно если под виндами работают. Для большинства десктопных задач добавление памяти сильнее повышает субъективно видимое быстродействие компа чем добавление процессора.

И приводил в пример свои компы где система свап почти никогда не использует. Хотя он ЕСТЬ

Значит, на этих системах смотрят котиков.

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

Свап никак на долговечность ssd не повлияет

Сильно спорить не буду потому что лично сам еще не «заездил» еще ни один из своих SSD(недорогих кстати). Но на технических форумах люди всё же пишут что влияет. И что винда с ее активным свапом убивает их быстрее чем линукс,который можно настроить так чтобы он свапом не злоупотреблял. Но всё это с чужих слов.

Почему ты все время соскакиваешь на тему «swap раздел vs swap файл»?

Потому что исходное обсуждение было о РАЗБИВКЕ ДИСКА(см.название темы),а не о принудительном отключении свапа. Но почему-то когда я сказал что свап-РАЗДЕЛ на диске не нужен - это было понято так как будто я предлагаю свап принудительно отключить совсем. Нет,такого я не предлагал и не предлагаю. А предлагаю использование свап-файлов,причем автоматически создаваемых по необходимости (на то демон специальный есть). Ну и упомянул что при достаточном количестве памяти создаются они крайне редко.

watchcat382
()
Ответ на: комментарий от hateWin

ты готов доказать, что свап позволяет использовать память эффективно, даже если она дешевая?

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

Пытаясь доказать «ненужность свапа в эпоху дешевой памяти»

Еще раз посмотрите на название темы - она о разбивке диска. И я пытался доказать ненужность отдельного РАЗДЕЛА на диске,а не ненужность свапа. Про сам свап я лишь сказал что при достаточном количестве памяти система САМА его не использует,без какого-либо кручения настроек вообще.

Вот,перечитайте еще раз что я писал:

www.linux.org.ru/forum/admin/17517708?cid=17781671

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)
Ответ на: комментарий от hateWin

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

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

Уменьшение пропускной способности канала увеличит конкуренцию между пирами за скорость этого самого канала. Твой диск они от этого дрючить не перестанут.

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

Давай перейдем к конкретике. Я уже давал тебе данные со своего компьютера. Возьми эти данные и ответь на вопрос: достаточно ли у меня памяти, или нет?

hateWin ★☆
()
Ответ на: комментарий от watchcat382

Вы застряли где-то в 90х-00 годах когда память стоила дорого. Сейчас 16 гигов памяти(обычной,не экзотики какой-то) стоят как пара походов в магазин за едой. Если для вас это «выбрасывать деньги» то ваша финансовая состоятельность вызывает сомнения

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

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

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

16 гигов это для вас «непомерное количество»?

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

Я же не 128+ гигов ставить предлагаю

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

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

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

hateWin ★☆
()
Ответ на: комментарий от watchcat382

Но на технических форумах люди всё же пишут что влияет

Учитывая, что ты уже давал ссылку на долбоклюев, неспособных прочитать официальную документацию к параметрам из /proc/sys/wm, я не удивлюсь, если люди с твоих «технических форумов» распространяют такую же чушь про «экономию ресурса ssd».

hateWin ★☆
()
Ответ на: комментарий от watchcat382

Потому что исходное обсуждение было о РАЗБИВКЕ ДИСКА(см.название темы)

Я в этом исходном обсуждении не участвовал. Я начал спорить с утверждением про ненужность свапа вообще. Хватит соскакивать с темы

hateWin ★☆
()
Ответ на: комментарий от hateWin

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

Свои я тоже публиковал выше по теме.

достаточно ли у меня памяти, или нет?

Маловато,но не критично. Вот у меня - достаточно.

watchcat382
()
Ответ на: комментарий от hateWin

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

С одной стороны вашу точку зрения тоже можно понять. Повышение эффективности использования любого ресурса это хорошо,но и доведение до абсурда тоже плохо. Взять к примеру процессор - можно купить какой-нибудь Атом и работать на нем. Он будет если не постоянно то достаточно регулярно загружен на 70-90%. Казалось бы - эффективное использование. Но будет тратиться ресурс,который невозможно купить ни по какой цене - время. И это делает невыгодной экономию даже «буханки хлеба» на процессоре. Возможна и другая крайность - приобретение какого-нибудь вычислительного монстра за тысячи баксов,для которого просто не найдется задач,способных его эффективно загрузить. Истина как всегда где-то посередине и каждый решает сам где именно. Мне - выгодно экономить время,но использовать «вычислительного монстра» я не могу по причинам ограниченности энергоснабжения в зимний период когда не работают солнечные панели (у меня полностью автономный дом в отдалённой и довольно труднодоступной местности). Поэтому я ставлю больше памяти чтобы система не использовала свап и тем самым выжимаю проценты производительности при меннее мощном процессоре.

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

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

Ты предлагаешь хранить в памяти холодные данные вместо часто используемых файловых страниц.

Если у вас действительно аж 8 гигов именно ЧАСТО используемых файловых страниц - то я с вами соглашусь. У меня нет таких объемов файловых операций чтобы был нужен столь огромный кэш. Кто знает - может вы там видеомонтажем в FullHD занимаетесь на полупрофессиональном уровне. Тогда и 8 гигов кэша мало может быть. И 16 гигов ОЗУ уж точно мало.

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

Последние годы компилирую код для микроконтроллеров. Он действительно небольшой размером. Фотки - FullHD,большего размера мне не нужны так как даже это ужимают на форумах куда они потом выкладываются,да и просто у тех кому отсылаю обычно нет мониторов с еще большим разрешением(не говоря о том что в полный экран обычно фотки не разворачивают при просмотре). Зачем параллельно открывать браузер вместе с редактором картинок - мне непонятно. Если я занят картинкой то я точно не лазаю по сайтам. Насчет плеера - согласен,но и audacious и deadbeef кушают очень мало. Торрентами очень давно не пользуюсь,сколько жрут нынешние качалки на знаю. Так что да - свап система себе создает крайне редко,обычно если я пытаюсь сделать что-то совсем уж странное. Поэтому использование автоматически создаваемых свап-файлов вместо выделенного на диске раздела - вполне оправдано.

watchcat382
()
Ответ на: комментарий от hateWin

я не удивлюсь, если люди с твоих «технических форумов» распространяют такую же чушь про «экономию ресурса ssd».

Согласен с вами,вполне может быть что это чушь. Я уже говорил,что лично у меня еще ни сдох ни один ssd,даже купленный в 2010 году еще жив. Но откуда-то же эти многочисленные рассуждения о ресурсе ssd всё-таки появились?

Более того, есть столь же распространенное мнение что многочисленные пуски и остановки механически HDD сокращают их ресурс. Однако я еще с конца 90х на всех своих домашних компах и ноутбуках использовал (до перехода на ssd) остановку шпинделей дисков при неактивности. Прямо с тех пор как эти ata-команды диски стали поддерживать. И никакой повышенной смертности дисков я не наблюдал. У меня сохранились диски объемом в сотни мегабайтов-единицы гигабайтов с тех еще времен и большинство из них включаются и читаются. Пару лет назад тоже был какой-то спор на форуме про ресурс дисков - ну я и проверил свои.

Увы - самостоятельно и объективно протестировать влияние разных факторов на живучесть разного компьютерного железа невозможно. Приходится принимать во внимание в том числе и «чушь» с форумов.

давал ссылку на долбоклюев

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

watchcat382
()
Ответ на: комментарий от hateWin

Как ты пришел к такому выводу?

Свап не пустой. А у меня - пустой.

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

watchcat382
()
Ответ на: комментарий от CrX

Ваш аргумент про докидывание памяти в любой ситуации — это как раз доведение до абсурда.

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

watchcat382
()
Ответ на: комментарий от watchcat382

Свап не пустой

Зато avaible 8 гигабайт против 2 в свапе. Почему система пользуется свапом даже тогда, когда доступно в четыре раза больше памяти, чем было вытеснено в свап?

hateWin ★☆
()
Ответ на: комментарий от watchcat382

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

Где мне купить хотя бы 2 ТБ памяти и материнку и проц с их поддержкой, и чтобы это не вышло «в копеечку»? Фиг с ним, ладно, хотя бы 512 ГБ где?


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

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 2)
Ответ на: комментарий от hateWin

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

А вот этого я не знаю. И проверить не могу потому что у меня не пользуется. Самому было бы интересно знать от чего это зависит

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

hateWin ★☆
()
Ответ на: комментарий от CrX

хотя бы 512 ГБ где?

Если у вас такие задачи что им реально надо 512 ГБ ОЗУ то без свапа вам не обойтись. Также как мне с моими задачами полтора десятка лет назад не обойтись было.

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

Да не сказал бы что очень уж аскетичное,тем более что это комп - домашний. Сомневаюсь что много людей дома на компе рисует и симулирует электронные схемы,отлаживает в симуляторе код для МК, и даже иногда делает 3Д модели чего-нибудь для отдачи в печать на 3д принтере. Я вон гребной винт для небольшого лодочного мотора в OpenSCAD считал например. Вот здесь фото есть одного из вариантов: https://forum.motorka.org/threads/6323/page-2#post-578759

Это даже хорошо

Так это как раз к вопросу об эффективности использования железа и об умении делать всякие интересные вещи простыми инструментами. Если бы я попытался поставить на свой комп винды и какой-нибудь солидворкс - хрен бы я вышеупомянутый винт сделал. Не хватиало бы ни возможностей компа ни моей квалификации.

не надо свой случай пытаться эксраполировать на всех

Так я нигде и не говорю что 16 гигов «хватит всем»(С). Понятно что есть задачи когда и 128 может быть мало. И тогда свап используется вынужденно. А не потому что это хорошо. Лет 15 назад мне под мои задачи тоже памяти регулярно не хватало и свап использовался. А лет 25 назад не хватало даже места на диске и приходилось очень активно пользоваться архиватором. Он конечно существенно повышает эффективность использования диска,но очень увеличивает затраты главного ресурса - времени. Ценность которого с возрастом только растёт. Это в молодости его много,а мне вот лет двадцать жить осталось (в роду долгожителей нет,а вот инсультники каждый первый).

watchcat382
()
Ответ на: комментарий от watchcat382

Если у вас такие задачи что им реально надо 512 ГБ ОЗУ то без свапа вам не обойтись

Нет. Им не «реально надо». Но если следовать вашему пунктику «чтобы даже кэш не заполнялся», то понадобится.

Да не сказал бы что очень уж аскетичное,тем более что это комп - домашний.

Просто поговорите с людьми вокруг. Я понимаю, что часто кажется, что типа «как у меня, так наверное и у всех». Но это не так.

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

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

CrX ★★★★★
()
Ответ на: комментарий от hateWin

бред про «свап приводит к тормозам»,

Да не бред. Это очень заметно когда система начинает «диском мигать». Другое дело что винды приучили пользователей к медленно работающему интерфейсу(тормоза в первую очередь в этом проявляются). Особенно заметны тормоза интерфейса если управление окнами повешено на хоткеи и необходимость елозить мышкой сильно сокращена. Просто когда я начинал работать на персоналках - массово использовался DOS,который свапа не имел и вообще давал очень низкие накладные расходы. Да и интерфейс был текстовый,от того тоже с низкими расходами памяти и проца. Там увидеть глазами как например перерисовывается меню - было невозможно,это происходило «мгновенно»,даже несмотря на 80286 процессор. Последние полтора-два десятка лет такой же субьективной мгновенности можно добиться и от линукса,что я и делаю. Очень многие даже не знают что интерфейс может работать так. Они к задержкам привыкли,для них это нормально.

watchcat382
()
Ответ на: комментарий от CrX

Теперь осталось понять, что должно мешать использовать свап не вынужденно, а просто потому что это хорошо

Тараканы. Ядреные такие, наверняка мутанты. Их даже мелок «Машенька» не берет

hateWin ★☆
()
Последнее исправление: hateWin (всего исправлений: 1)
Ответ на: комментарий от hateWin

почему система управляет памятью именно так.

Но у меня на компах она «так» не работает. Свапа нет даже если например KiCAD запущу и какую-нибудь из своих схем в нем открою. Да и не только у меня. Полистайте даже этот форум - найдёте отзывы людей которые свап выключают вообще когда устанавливают много памяти. И вполне в эту память помещаются со своими задачами. Еще раз повторю,что в отличие от них я свап НЕ отключаю. Но системе он не нужен судя по тому что он пустой.

А у тебя все ответы сводятся к тому, что экономить плохо

Экономить хорошо. Только не память,а время пользователя. Время - это ресурс,который невозможно купить за деньги, в отличие от дешевой памяти.Еще раз повторю,что в отличие от вышеупомянутых я свап НЕ отключаю. Но системе он не нужен судя по тому что он пустой. Значит я экономлю правильно.

Хм… А может дело в том что я использую (с 1996 года) классический 32-битный Дебиан,а не модные сейчас x86-64 дистрибутивы? Нет у меня задач,в которых 64-битность дает хоть сколько-нибудь заметные преимущества по времени исполнения.

watchcat382
()
Ответ на: комментарий от watchcat382

Если у вас действительно аж 8 гигов именно ЧАСТО используемых файловых страниц - то я с вами соглашусь. У меня нет таких объемов файловых операций чтобы был нужен столь огромный кэш. Кто знает - может вы там видеомонтажем в FullHD занимаетесь на полупрофессиональном уровне.

Это компиляция ведра. Но можно обойтись и без компиляции. Прямо сейчас кроме огнелиса, терминала и файлового менеджера ничего не запущено. А четыре гигабайта buff/cache набралось. В свапе, правда, сейчас практически пусто, но только потому, что нет существенного давления на память, и свободных страниц еще 7.6 гигабайт.

hateWin ★☆
()
Ответ на: комментарий от watchcat382

Экономить хорошо. Только не память,а время пользователя

Так свап его и экономит. За счет сохранения файловых страниц в памяти. Без свапа система будет обращаться к диску чаще.

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

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

Хм… А может дело в том что я использую (с 1996 года) классический 32-битный Дебиан,а не модные сейчас x86-64 дистрибутивы?

32 бита

4 гигабайта RAM

не используется свап

Ккккккккомбо!!!! Ты понимаешь кретинизм ситуации? Ты рассказывал байки про ненужность свапа, аргументируя это тем, что в твоей системе он не используется. Оказалось, что секрет этого аскетизма в том, что у тебя тупо не хватает виртуальных адресов для работы свапа. Да ты просто кладезь кулхацкерских «оптимизаций» и «советов»

hateWin ★☆
()
Ответ на: комментарий от watchcat382

Хм… А может дело в том что я использую (с 1996 года) классический 32-битный Дебиан,а не модные сейчас x86-64 дистрибутивы? Нет у меня задач,в которых 64-битность дает хоть сколько-нибудь заметные преимущества по времени исполнения.

Ух!

Всё.

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

Спасибо! Искренее спасибо тебе, @watchcat382, это было круто. Именно как эдакое философско-драматическое произведение в виде постановки на форуме. Я понимаю, что не намерено, но круто, блин. Ты, наверное, сам ещё не понимаешь, что сделал.


P.S. Когда я стану совсем старым и таки решу писать книжки, ты не против, если я этот сюжет с «почему же у меня не используется свап при swappiness 60» заюзаю (художественно переработав), без указания «авторских прав»?

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

+>Просто поговорите с людьми вокруг.

Так у них как правило винды. Они вызывают субьективное ощущение тормозов на любом железе домашнего уровня.

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

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

Выше вон еще zram и zswap предлагались. А почему тогда и не файловая система с возможность сжатия файлов на лету? Можно же место сэкономить и покупать диск эдак на треть меньше. Почему если «надо» экономить ОЗУ то не надо экономить диск?

watchcat382
()
Ответ на: комментарий от watchcat382

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

Эх, сколько нам открытий чудных готовит просвещения дух…

hateWin ★☆
()
Ответ на: комментарий от hateWin

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

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

А также есть разница - задержки везде в интерфейсе или задержки при относительно редких файловых операциях. Одно дело когда интерфейс тормозит при рисовании каждого окна и даже меню,мигая при этом диском из-за свапа, и совсем другое если возникает пауза при нажатии на Save в конце этапа работы. За более подробными объяснениями почему так - почитайте например вот эту книгу «Интерфейс человек-компьютер» Влейминк И., Коутс Р. Она есть в продаже в Озоне. Там описаны результаты научных исследований в области человеко-машинного взаимодействия. И у меня такое впечатление что авторы сегодняшних интерфейсных библиотек это не читали.

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

А также есть разница - задержки везде в интерфейсе или задержки при относительно редких файловых операциях.

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

hateWin ★☆
()
Ответ на: комментарий от hateWin

Это компиляция ведра.

Самые последние не компилировал - на десктопе это уже довольно давно не нужно,а в одноплатниках обычно используются более старые ядра в целях экономии размеров так как чего-то особо продвинутого из новых ядер там обычно не надо. Например в андроидных планшетах по сей день регулярно попадаются ядра аж 3.Х. И их компиляция даже при четырех гигах свапа не просит. Разве что может быть если многопоточную запустить - вот это не пробовал на четырех гигах.

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

У меня Vivaldi,Sylpheed,Midnight Commander и Audacious. Кэша 1 гиг,свап как обычно пустой. Тут я замечу,что размер кэша зависит от аптайма - я всего полтора часа назад этот комп включил чтобы форум почитать(и больше ничего делать не собирался сегодня перед сном). Со временем кэш сам по себе разрастается и занимает всю память также как газ заполняет собой весь объем сосуда(сравнение не моё но верное,откуда-то с англоязычных форумов). Это не значит что всё содержимое этого кэша нужное - там окажется любой даже однократно прочитанный файл. Просто чтобы память без дела не простаивала.

В свапе, правда, сейчас практически пусто

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

 free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       776Mi       2.0Gi       208Mi       1.0Gi       2.5Gi
Swap:          3.9Gi          0B       3.9Gi

Еще уточню что это классическая 32-битная сборка Дебиана,а не x86-64

watchcat382
()
Ответ на: комментарий от watchcat382

Самые последние не компилировал - на десктопе это уже довольно давно не нужно

Там драйверы, если ядро в дистрибутиве старее компьютера, то нужно. Я компьютер купил в этом году, Slackware 15.0 вышел в 2022, без нового ядра не видит Bluetooth, Wifi, нету хорошей поддержки P/E ядер.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от hateWin

Без свапа система будет обращаться к диску чаще.

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

у тебя тупо не хватает виртуальных адресов для работы свапа.

И где вы эту чушь откопали? Пожалуйста ссылку на источник где сказано что на 32-битных системах свап не может работать потому что ему видите ли не хватает виртуальных адресов. Ибо практика вашим словам не соответствует. Если например запустить генерацию 3д-модели с избыточно высокой (для целей печати) детализацией - то OpenSCAD и памяти много сожрёт и в свап залезет. Сам лично это наблюдал когда с ним возился. И «виртуальных адресов» ему вполне хватит. Вообще-то i386 позволяет адресовать 64 гигабайта виртуальной памяти.

Да ты просто кладезь кулхацкерских «оптимизаций» и «советов»

А я всего-то посоветовал не выделять отдельный раздел под свап на диске(использовать файл) и ставить побольше памяти чтобы свап использовался поменьше и пореже. И что тут не так?

Вообще-то не так тут ваш невежливый стиль беседы,но спишем это на ваши индивидуальные ментальные особенности.

watchcat382
()
Ответ на: комментарий от watchcat382

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

Я же сказал, нагугли размер виртуального адресного пространства в 32 битных системах. Может, дойдет. Хотя надежда слабая

hateWin ★☆
()
Ответ на: комментарий от hateWin

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

Еще раз повторяю,что я нигде ни разу не предлагал его отключать. Наоборот,я предлагал использовать демона,автоматически создающего свап-файлы по мере надобности. Сколько угодно,пока диск не кончится. А не ограничиваться выделенным разделом жестко заданной и не слишком большой емкости.

watchcat382
()
Ответ на: комментарий от CrX

ты не против, если я этот сюжет с «почему же у меня не используется свап при swappiness 60» заюзаю

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

watchcat382
()
Ответ на: комментарий от hateWin

Ты уже нагуглил, насколько ограничено виртуальное адресное пространство x86?

В отличие от вас, я даже когда-то в 90х писал ассемблерный код под защищенный режим i386 и про ограничение в 64 гига знаю еще с тех времен. Но к свапу это прямого отношения не имеет. В Дебиане от как работал так продолжает,в том числе и в 32-битной сборке. А к примеру монтажем видео где нужны непрерывные области памяти гигантских размеров - я не занимаюсь.

watchcat382
()
Ответ на: комментарий от watchcat382

В отличие от вас, я даже когда-то в 90х писал ассемблерный код под защищенный режим i386 и про ограничение в 64 гига знаю еще с тех времен

Если знаешь — ответь на вопрос: что означает P в аббревиатуре PAE?

hateWin ★☆
()
Ответ на: комментарий от watchcat382

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

Да тут вообще не в этом дело. Прям совсем не в этом. Неужели ты так и не понял?

CrX ★★★★★
()
Ответ на: комментарий от hateWin

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от hateWin

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

А как это связано со свапом? Четыре гига это ограничение на один процесс(непрерывный кусок если угодно),а не на всю доступную системе память. Но у меня нет таких процессов которым при обычной работе четыре гига надо. А система видит и использует все 16 гигов что есть в компе. И свап прекрасно используется если специально постараться и чем-нибудь всю память занять.У меня задач с такими требованиями нет,но искусственно создать такую ситуацию не трудно.

Вот какая-то из первых редакций WinXP помню была - она реально больше четырех гигов не видела сколько ни поставь в комп.

watchcat382
()
Ответ на: комментарий от MOPKOBKA

Адресное пространство процесса — часть общего адресного пространства. Сам процесс вообще не в курсе, где лежит та или иная часть его памяти. А система в курсе, но у нее не хватает адресов:)

hateWin ★☆
()
Ответ на: комментарий от MOPKOBKA

Там драйверы, если ядро в дистрибутиве старее компьютера, то нужно.

Нисколько не спорю,изредка бывают случаи когда нужно - это в первую очередь ноутбуки с проблемными BT и WiFi которые там естественно не заменить. Но мы тут говорим про десктопы,где обычно можно выбрать что в комп воткнуть и втыкать то что давно и хорошо совместимо с линуксом. Тогда можно обойтись без перекомпиляции ядра. Я и сам помню как лет 15-20 назад буквально каждая переустановка системы начиналась с компиляции ядра. Но сейчас чаще всего всё сразу работает. Вот у меня под рукой моноблок от Асус которому всего-то лет пять. И моноблоки эти штука довольно экзотическая,они по внутренностям родственны ноутам,а не десктопам. Однако звук и даже поддержка встроенной в проц интеловской графики завелись сразу. А wifi у меня в роутере к которому стационарные компы проводами подключены. Оно для планшетов надо,которые часто проводами не умеют.

watchcat382
()
Ответ на: комментарий от hateWin

Адресное пространство процесса — часть общего адресного пространства.

Какого пространства именно? Если физического, то несомненно, физ.память процесса это часть физ.памяти. Виртуального? Тогда два процесса занимающих 4 гб нельзя было бы создать.

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Я тоже говорю про десктоп, чипсет z790, сейчас на десктопах WIFI и Bluetooth прямо на матплате. Тоже самое и с видеокартами AMD, драйверы все в ядре. У NVidia с драйверами все лучше, можно поставить отдельно, я так и делаю. Но если бы я хотел пользоваться nouveau, то пришлось бы тоже ставить новое ядро, потому что только там есть поддержка серии RTX 4000.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от watchcat382

А как это связано со свапом?

А как, по твоему, адресуется свап?

Четыре гига это ограничение на один процесс

Это ограничение на объем виртуального адресного пространства в принципе. И ограничение на память процесса как следствие, поскольку адресное пространство процесса — подмножество общего адресного пространства. Но в реальности все ещё хуже. Ядро резервирует для себя гиг. Исполняемые файлы и библиотеки мапятся в память каждого процесса и занимают виртуальное адресное пространство, даже если не занимают физическую память. То же касается и обычных файлов, с которыми работает процесс. Так что на практике больше двух гигов на процесс у тебя не будет

hateWin ★☆
()
Ответ на: комментарий от hateWin

надежда слабая

Да я понял уже что вы путаете ограничение адресного пространства на один процесс,так сказать непрерывного куска(4Гб) и общее доступное адресное пространство для i386 - 64 Гб. А еще и PAE есть которым ядро тоже умеет пользоваться. Будь по вашему - 32-битный линукс не видел бы памяти больше 4 гигов как древняя WinXP. А он видит,работает,и свап при необходимости тоже использует. Просто вы не углублялись в эти детали.

watchcat382
()
Ответ на: комментарий от MOPKOBKA

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

Что ты имеешь ввиду? Разверни мысль

hateWin ★☆
()
Ответ на: комментарий от hateWin

Тебе буква P в PAE ни на какие мысли не наводит?

Идите в википедию и прочитайте статью про 80386.

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

Да я понял уже что вы путаете ограничение адресного пространства на один процесс

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

общее доступное адресное пространство для i386 - 64 Г

PAE – чудовищный костыль. Не говоря уже о том что это касается физической памяти, а не виртуальной

hateWin ★☆
()
Ответ на: комментарий от MOPKOBKA

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

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

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

watchcat382
()
Ответ на: комментарий от hateWin

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

https://stackoverflow.com/a/12777127

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 3)
Ответ на: комментарий от watchcat382

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» без подсказки найдешь?

hateWin ★☆
()
Ответ на: комментарий от hateWin

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

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

watchcat382
()
Ответ на: комментарий от MOPKOBKA

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

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

hateWin ★☆
()
Ответ на: комментарий от MOPKOBKA

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

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

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

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

watchcat382
()
Ответ на: комментарий от hateWin

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

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

watchcat382
()
Ответ на: комментарий от hateWin

Что ты несёшь?! 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
В свапе какие-то 700М, при этом 2G памяти вообще не распределено, то есть эти 700М можно было там и оставить без какого-либо вреда (скорее всего они учтены как «available», то есть без свапа были бы те же 2G free, а вот из avail 700M превратились бы в used). Так что ОС просто зря потратила время на зеркалирование этих страниц в свап. Но да, это частный случай, конечно не всегда так.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от CrX

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

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

watchcat382
()
Ответ на: комментарий от hateWin

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

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

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 3)
Ответ на: комментарий от watchcat382

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

hateWin ★☆
()
Ответ на: комментарий от watchcat382

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

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

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

firkax ★★★★★
()
Ответ на: комментарий от hateWin

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

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

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

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

watchcat382
()
Ответ на: комментарий от MOPKOBKA

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

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

hateWin ★☆
()
Ответ на: комментарий от hateWin

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

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 3)
Ответ на: комментарий от hateWin

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

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

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

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

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

MOPKOBKA ★★★★★
()
Ответ на: комментарий от watchcat382

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

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

CrX ★★★★★
()
Ответ на: комментарий от hateWin

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от hateWin

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

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

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

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

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от firkax

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

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

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

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

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

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

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

CrX ★★★★★
()
Ответ на: комментарий от hateWin

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

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

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

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

watchcat382
()
Ответ на: комментарий от CrX

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от firkax

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

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

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

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

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

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

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

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

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

watchcat382
()
Ответ на: комментарий от MOPKOBKA

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

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

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

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от CrX

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

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 4)
Ответ на: комментарий от MOPKOBKA

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

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

watchcat382
()
Ответ на: комментарий от hateWin

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

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

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

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

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

watchcat382
()
Ответ на: комментарий от MOPKOBKA

чипсету z890

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

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

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

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)
Ответ на: комментарий от CrX

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

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

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

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

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

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

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

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 6)
Ответ на: комментарий от hateWin

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

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

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

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)
Ответ на: комментарий от watchcat382

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

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

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

CrX ★★★★★
()
Ответ на: комментарий от CrX

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

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

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

watchcat382
()
Ответ на: комментарий от CrX

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

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 3)
Ответ на: комментарий от MOPKOBKA

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

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

watchcat382
()
Ответ на: комментарий от CrX

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

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

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

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

watchcat382
()
Ответ на: комментарий от CrX

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

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

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

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

MOPKOBKA ★★★★★
()
Ответ на: комментарий от watchcat382

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

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

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

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

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

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

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

CrX ★★★★★
()
Ответ на: комментарий от MOPKOBKA

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

MOPKOBKA ★★★★★
()
Ответ на: комментарий от MOPKOBKA

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

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

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

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

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

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)
Ответ на: комментарий от watchcat382

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

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 4)
Ответ на: комментарий от CrX

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

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

watchcat382
()
Ответ на: комментарий от MOPKOBKA

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

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

watchcat382
()
Ответ на: комментарий от firkax

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

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

watchcat382
()
Ответ на: комментарий от CrX

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

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

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

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

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

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

watchcat382
()
Ответ на: комментарий от firkax

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

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

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

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

firkax ★★★★★
()
Ответ на: комментарий от MOPKOBKA

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

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

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

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

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

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

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

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

watchcat382
()
Ответ на: комментарий от MOPKOBKA

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

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

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от firkax

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

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

hateWin ★☆
()
Ответ на: комментарий от firkax

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

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

hateWin ★☆
()
Ответ на: комментарий от watchcat382

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

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

hateWin ★☆
()
Ответ на: комментарий от hateWin

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

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

firkax ★★★★★
()
Ответ на: комментарий от hateWin

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

hateWin ★☆
()
Ответ на: комментарий от hateWin

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

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

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

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

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

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

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

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

hateWin ★☆
()
Ответ на: комментарий от hateWin

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

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

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

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

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

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

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

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

firkax ★★★★★
()
Ответ на: комментарий от hateWin

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

struct process {
  ptr64 pages[1048576];
};

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

Допустим, в коде (обычном) встречается чтение из ячейки с адресом p:
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), вся логика остаётся как была.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от hateWin

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

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

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

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

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

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

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

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

«среднетипичный десктоп» в 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
watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

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

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

watchcat382
()
Ответ на: комментарий от anc

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

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

watchcat382
()
Ответ на: комментарий от watchcat382

«вэбня» это что? Если обычное лазание по сайтам - то да,согласен.

Я именно про это.

Хотя конечно я читал здесь на Лоре про каких-то странных людей,которые открывают в браузере открывают аж сотни вкладок.

А сотен и не надо. Достаточно одного сайтега но сильно жрущего.

anc ★★★★★
()
Ответ на: комментарий от watchcat382

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

Одновременных. Но не схороненных.

anc ★★★★★
()
Ответ на: комментарий от anc

Достаточно одного сайтега но сильно жрущего.

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

watchcat382
()
Ответ на: комментарий от watchcat382

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

Зачем? Особенно в мобильных браузерах. В десктопных по старой привычке использую закладки, но сейчас они (десктопные браузеры) не так часто и нужны. В мобильных это неудобно, проще не закрывать вкладки, пока они могут быть нужны.

anonymous
()
Ответ на: комментарий от anonymous

что надо сделать чтобы браузеру не хватило четырех гигов?

Открыть вторую вкладку.

На каком сайте это надо сделать? Хочу померить сколько у меня скушает. Пользуюсь Vivaldi.

watchcat382
()
Ответ на: комментарий от anonymous

В десктопных по старой привычке использую закладки

Аналогично.

В мобильных это неудобно

На лично мой вкус лазать по интернету мобильным браузером вообще неудобно,видимо из-за многодесятилетней привычки к десктопу. Даже несмотря на то что у меня достаточно большой планшет Lenovo YT3-X50M. Поэтому для интернета использую очень редко. Обычно книги с него читаю.

watchcat382
()
Ответ на: комментарий от anc

Предлагаете перейти на однозадачность?

А вы умеете одновременно читать десятки страниц? У меня больше нескольких не получается. При этом браузер(vivaldi) кушает немного. Даже на таких толстых сайтах как Авито.

watchcat382
()
Ответ на: комментарий от anc

Извините

Извиняю. И тоже периодически читаю как у людей браузер сжирает какие-то немыслимые объемы памяти. Правда обычно это про Хром пишут. У меня Vivaldi,а в прошлом десятилетии был Файрфокс. Ни тот ни другой как-то не отличались неумеренным аппетитом.

watchcat382
()
Ответ на: комментарий от watchcat382

А вы умеете одновременно читать десятки страниц?

Нет. Но я могу оставить н-цать незакрытых потому что... например они мне не нужны в букмарках, но дочитать планирую позже. Или на примере лора, мне просто лень пальчиками шевелить на тему набрать linux.org.ru когда оно и так открыто.

anc ★★★★★
()
Ответ на: комментарий от watchcat382

И тоже периодически читаю как у людей браузер сжирает какие-то немыслимые объемы памяти.

Такое бывает.

Правда обычно это про Хром пишут.

Та какая разница про что? Все они жрут или не жрут в зависимости от самих страничек.

У меня Vivaldi,а в прошлом десятилетии был Файрфокс.

Вы однолюб?

anc ★★★★★
()
Ответ на: комментарий от watchcat382

У меня Vivaldi,а в прошлом десятилетии был Файрфокс.

Вы однолюб?

Нет, вот как раз сменил файрфокс на вивальди.

Это и есть однолюб. Есть разница между «любимый молоток» и «единственный молоток».

anc ★★★★★
()