Почему Linux тормозит

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

Я вот не увидел у него размер раздела, указан только размер диска, 250 Гб.

Если у него один большой раздел на весь диск, то фрагментация будет не хилая, в особенности если у него диск заполнен процентов на 50 и больше и он обновляет систему, куда по вашему будут записываться файлы устанавливаемых пакетов и как ? Как минимум, даже если файл разместиться одним куском, он хотя бы уже будет располагаться ближе к краям магнитных пластин диска. В том врем как остальные файл с /usr расположены в начале диска. Теперь представьте момент, у вас запускается программа, бинарный файл, к примеру после установки поместился в начале диска, а библиотеки этой программы расположились где попало, но существенно ближе к внешнему краю магнитных пластин. Что же будет происходить при запуске это программы ? А вот что бинарник прочитается в память, затем начнут подгружаться библиотеки, одна с середины физической ёмкости диска, другая ближе к концу, а третья опять, к примеру с начала диска. Время запуска программы увеличится. Плюс у него винт старый, скорее всего скорость линейного чтения не превышает 40-45 мб./сек. отсюда и все тормоза.

Этого бы не было в случае выделения /usr, в частности как отдельного раздела в начале физической ёмкости диска, все данные, необходимые для работы программы были бы рядом, в предела 5 Гб и не размазывались бы по всему диску.

Я его на powerpc c OS System 7 видел в середине 90-ых. И чего?:)

да причём здесь скорость чтения вообще? Быстродействие ОС всегда зависело от времени доступа.

а библиотеки этой программы расположились где попало,

да не будут они расположены где попало. С какой кстати, после записи на диск(при установке) система вознамерится эти RO библиотеки перезаписывать?

да причём здесь скорость чтения вообще? Быстродействие ОС всегда зависело от времени доступа.

Вы спросите у ТС что он подразумевает под «Linux Тормозит», время запуска приложения тоже к этому относится, а от скорости чтения с диска зависит как быстро прочитаются с диска все необходимые приложению для работы компоненты. Опять же если при выполнении какого-либо действия в приложении нужно дочитать файл / библиотеку это всё опять же упирается в скорость чтения.

да не будут они расположены где попало. С какой кстати, после записи на диск(при установке) система вознамерится эти RO библиотеки перезаписывать?

А вы вот раз систему поставили и потом её не обновляете, не устанавливаете новые компоненты ? В этом случае, конечно как лежало так и будет лежать.

Теперь представьте другую ситуацию: ТС поставил систему, у него всё в одном разделе, установил нужный ему софт. Всё быстро работает, он доволен. ТС начинает писать на жёсткий диск большие объёмы данных, например пользуется p2p / торрентами, у него записывается на диск довольно большой объём данных. Затем он решает обновить систему, у него обнволяются часть компонентов, доустанавливаются новые, куда они по вашему мнению запишутся ? Естественно часть, возможно перезапишет обновляемые файлы, но врядли всё целиком ляжет опять в начале диска, где лежит большая часть файлов на /usr, всё же часть ляжет после записанных ТС файлов на диск, торрентов в частности, при чём может лечь не целиком файл а его часть. Потом ТС ещё что-то просто доустанавливает. В итоге файлы, которые расположены в /usr теперь помещаются не в пределах 5 Гб, как было бы в случае выделения отдельного раздела под /usr ну или хотя бы 10-15 Гб под корень, а «размазаны» по всему диску.

Ну вот теперь и представьте что будет со временем с системой.

Не, я не пытаюсь показаться крутым перед новичком, это действительно было 5 лет назад, в 2007-2008 году на форуме ubuntu.opentomsk.net. Статью нашёл и дал ему.

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

диагноз у тебя, если ты не понимаешь, что сжатые данные надо разжимать, а это - время. То самое время, которое ты хотел сэкономить. ИЧСХ, что там у ТСа с фрагментацией - неизвестно, скорее всего всё у него нормально (ext4 не склонна к фрагментации), а вот сжатие приведёт к гарантированным тормозам.

К сожалению не понял вашего выражения, скорее всего оно употребляется в среде курящих пони.

«или» употребляется в среде русско-говорящих людей, для разделения альтернатив. Т.е. ИЛИ оптимизация по размеру -Os, ИЛИ оптимизация по времени -O3 (или -O2).

Союз «И» употреблён тобой неправильно.

ЗЫЖ и вообще, в твоей мессаге и без этого полно бреда, но этот самый заметный и бредовый.

Да не об этом, все это решения 20-летней давности

Мне на Gentoo хватает, а ему мало.

мало. И то, я прекрасно знаю, чего я хочу. А вот ТС не знает. А значит - ему надо ещё больше.

как никак сам компилял

а гентушники говорили, что их компьютер сам компиляет. Кому верить?

сейчас в генте появляются подобия бинарников (того же OO), дабы люде не компиляли сутками

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

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

вынужден согласится по всем пунктам.

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

Мда у меня уже 2 года работает система со сжатым /usr в squashfs образе и прекрасно работает, время запуска приложений только сократилось. Если ты не в теме то не надо об это ничего говорить. Для современных процессоров распаковать сжатый в xz файл ничего не стоит, он будет дольше считываться с диска. Кроме всего прочего при сжатии в squashfs файлы упорядочиваются и создаётся индекс файлов, как следствие это ускоряет процесс поиска файла.

(ext4 не склонна к фрагментации)

С чего это она не склонна к фрагментации, заполните файловую систему на процентов на 75 и посмотрите.

ЗЫЖ и вообще, в твоей мессаге и без этого полно бреда, но этот самый заметный и бредовый.

Мда и это говорит зелёный пони с сигаретой. Ну-ну.

Если у него один большой раздел на весь диск, то фрагментация будет не хилая, в особенности если у него диск заполнен процентов на 50 и больше и он обновляет систему,

тормоза будут, но не из-за фрагментации. Просто у него /bin/true будет на одном конце диска лежать, а нужная ей libc.so.6 на другом. Потому будет долго грузится. Да и запускаться ПО будет медленно. Но НЕ из-за фрагментации.

Время запуска программы увеличится.

ага. Где-то до 100mS. Какая разница-то, ты моргаешь дольше.

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

в рассматриваемом тобой случае, линейная скорость ни на что не влияет.

Этого бы не было в случае выделения /usr, в частности как отдельного раздела в начале физической ёмкости диска, все данные, необходимые для работы программы были бы рядом, в предела 5 Гб и не размазывались бы по всему диску.

а вот и нет. Смотри: у тебя программа на одном конце диска, а все её данные - на другом. Вот оно так и будет прыгать по всему диску всю дорогу. Сюрприз?

100mS

миллисименс?

Да и запускаться ПО будет медленно. Но НЕ из-за фрагментации.

Огласи свою методику измерения. На основании чего ты делаешь такой вывод?

тормоза будут, но не из-за фрагментации. Просто у него /bin/true будет на одном конце диска лежать, а нужная ей libc.so.6 на другом. Потому будет долго грузится. Да и запускаться ПО будет медленно. Но НЕ из-за фрагментации

На почитай я уже распил твоему коллеге по форуму, который так же упирается вот в этом сообщении: Почему Linux тормозит (комментарий)

ага. Где-то до 100mS. Какая разница-то, ты моргаешь дольше.

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

а вот и нет. Смотри: у тебя программа на одном конце диска, а все её данные - на другом. Вот оно так и будет прыгать по всему диску всю дорогу. Сюрприз?

Что ты подразумеваешь под её данными ? Я же ясно вроде написал бинарный файл и необходимые для его работы библиотеки, сюда же можно отнести графические файлы для отрисовки интерфейса, звуковые для звукового сопровождения и прочее, всё, что в общем необходимо для запуска приложения, всё это лежит в /usr, для закрытых программ в /opt. В итоге при небольшом /usr программа быстро запускается, в особенности, если /usr ещё и зажат в squashfs, можешь упираться сколько угодно, но это ускоряет запуск. Проверь если нет опыта по этому вопросу. А вот когда ты уже открываешь в программе, например видео редакторе, видое плеере, аудио плеере, в общем что угодно, файл для работы тогда да, для чтения файла магнитным головкам нужно переместиться в другую область диска. Но время за которое программа будет готова к работе будет минимальным.

Мда у меня уже 2 года работает система со сжатым /usr в squashfs образе и прекрасно работает, время запуска приложений только сократилось.

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

Если ты не в теме то не надо об это ничего говорить.

я-то как раз в теме.

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

бред. Файл, сжатый xz требует довольно много памяти для распаковки, и она ни в один кеш не влезет. Потому скорость распаковки довольно низкая (хотя CPU при этом действительно простаивает). И это при условии, что тебе хватит кеша и на запакованные файлы, и на распакованные, и ещё и на нужды xz останется.

Кроме всего прочего при сжатии в squashfs файлы упорядочиваются и создаётся индекс файлов, как следствие это ускоряет процесс поиска файла.

ага. И индекс тоже в памяти. Ты хотя-бы 8Гб для ТСа уже купил?

С чего это она не склонна к фрагментации, заполните файловую систему на процентов на 75 и посмотрите.

на 75% нормально заполняется. Вот на 95% действительно проблемы (именно потому, по умолчанию 5% недоступно, кстати. А не только и не столько для рута). Но мы не знаем, что там у ТСа.

Мда и это говорит зелёный пони с сигаретой. Ну-ну.

это говорю я. А пони - твоя укуренная галлюцинация ☺

миллисименс?

миллисекунд.

Да и запускаться ПО будет медленно. Но НЕ из-за фрагментации.

Огласи свою методику измерения. На основании чего ты делаешь такой вывод?

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

Вангую это, причем проявляется не везде:
https://bugs.launchpad.net/ubuntu/ source/gnome-settings-daemon/ bug/969359

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

То есть ты не проверял. Провёл мысленный эксперимент и сделал вывод?

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

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

бред. Файл, сжатый xz требует довольно много памяти для распаковки, и она ни в один кеш не влезет. Потому скорость распаковки довольно низкая (хотя CPU при этом действительно простаивает). И это при условии, что тебе хватит кеша и на запакованные файлы, и на распакованные, и ещё и на нужды xz останется.

Мда, а кто распаковывать-то тогда будет, если CPU простаивает. Распаковка в памяти пройдёт быстрее чем у файл прочитается.

ага. И индекс тоже в памяти. Ты хотя-бы 8Гб для ТСа уже купил?

Не поверишь, у меня действительно 8 Гб RAM и Core 2 Quad 8600, так что на этой конфигурации бонусы от сжатия в squashfs ощущаются. К сожалению на другом ПК с Phenom II x4 945 так же не могу опровергнуть своего утверждения о том, что сжатие в squashfs даёт ускорение в запуске приложений. И ещё на ряде ПК тоже, к сожалению не могу опровергнуть, среди них есть как ноут с Core i3, так и ноут с Celeron 1700, на последнем алгоритм сжатия, конечно не xz, а gzip, но скорость запуска приложений так же повысилась.

я-то как раз в теме.

Что-то сомневаюсь.

В общем если я привёл рекомендацию, то её надо использовать в соответствие с особенностями имеющегося у тебя оборудования и изменять параметры. Скорее всего ты не смог корректно подобрать параметры / настройки.

это говорю я. А пони - твоя укуренная галлюцинация

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

На почитай я уже распил твоему коллеге по форуму, который так же упирается

ну если валить всё в одну кучу, то так оно и будет конечно. Хотя фрагментация тут не при чём. Да и вообще ФС. И даже ОС(хотя в венде разделить данные конечно сложнее)

По сути, скорость запуска chromium`а, да и других программ увеличилась

ну я рад за тебя. Если-бы ты ещё и выводы научился правильные делать…

Что ты подразумеваешь под её данными ?

для большинства программ есть ещё временные файлы, которые она держит в ~, временные файлы, которые она держит в /tmp, и временные файлы, которые она держит в /var/tmp/. Ну и ещё чего-нить. Но эти она долбит постоянно, причём с O_SYNC, дабы ничего не потерялось(потому они НЕ кешируются).

если /usr ещё и зажат в squashfs, можешь упираться сколько угодно, но это ускоряет запуск. Проверь если нет опыта по этому вопросу.

забыл, кто slax пропагандировал? этот любопытный и полезный дистр вообще был-бы невозможен, если-бы не aufs. Оно конечно ускоряет ЗАПУСК, но замедляет загрузку, и ест память. Фактически, это такой автоматический RAM диск. Ежу понятно, что с RAM диска программы запускаются быстрее, чем с моего SSD ☺

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

намного раньше надо. Кроме чтения файлов из /usr/, практически все программы ещё и читают/пишут /tmp, /var и ~/. Потому толку _только_ от сжатия /usr/ обычно немного.

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

То есть ты не проверял.

проверял. Вот и ты проверь…

Подытожу, да, я забыл сказать, но у меня в /tmp и /var/tmp монтируется tmpfs. Да, признаю это забыл, надеюсь теперь ясно, что это не скажется на времени запуска приложения.

Оно конечно ускоряет ЗАПУСК, но замедляет загрузку, и ест память.

Чем же в твоём понимании от замедляет загрузку ? Нет, конечно aufs создаёт дополнительные накладки, но вот замедлять загузку это вряд ли.

Вот и ты проверь…

Огласи свою методику измерения.

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

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

Мда, а кто распаковывать-то тогда будет, если CPU простаивает. Распаковка в памяти пройдёт быстрее чем у файл прочитается.

CPU простаивает потому, что ждёт RAM. RAM достаточно медленная штука, если её долбить много, часто, и рандомно. А твой xz именно так и делает. Он и не распараллеливается, именно по этой причине - форк делали, но толку от него чуть.

Не поверишь, у меня действительно 8 Гб RAM и Core 2 Quad 8600

правильно. Потому-то У ТЕБЯ в камень и в память не упирается. Но то у тебя.

В общем если я привёл рекомендацию, то её надо использовать в соответствие с особенностями имеющегося у тебя оборудования и изменять параметры. Скорее всего ты не смог корректно подобрать параметры / настройки.

я? УМВР.

Огласи свою методику измерения.

На глазок, очевидно же :)

Подытожу, да, я забыл сказать, но у меня в /tmp и /var/tmp монтируется tmpfs. Да, признаю это забыл, надеюсь теперь ясно, что это не скажется на времени запуска приложения.

вот видишь? я угадал. А ты говоришь - не в теме.

Кстати /var/tmp ты зря в память засунул, приложения ждут, что после перезагрузки этот каталог не исчезнет. И пишут туда немного.

Чем же в твоём понимании от замедляет загрузку ? Нет, конечно aufs создаёт дополнительные накладки, но вот замедлять загузку это вряд ли.

ну я же объясняю - грубо говоря, это такой RAM диск, который сам разворачивается в память. Удобная и годная штука. Особенно если у тебя quad+8Gb. Или если у тебя slax на тормозной флешке (там да, читать очень долго надо, пока читаешь, можно 10 раз распаковать). Но вот на быстром HDD - не факт. Может лучше будет, а может и хуже. Если памяти не хватит - будет ППЦ.

CPU простаивает потому, что ждёт RAM.

Ну и бре-ед. Потом не отнекивайся, что, мол, имел в виду другое. :)

Но то у тебя.

На atom n270 в проц и камень не упирается.

Огласи свою методику измерения.

тебе напрямую не проверить моё утверждение? Повторю:

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

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

Головой надо думать стоит что-то делать или нет, а это как раз тот самый случай. Если процессор медленный и жёсткий диск медленный, то тут уже ничего не поможет, хотя можно купить SSD. Если процессор не особо быстрый, но ещё более-менее, то как я уже сказал не большие разделы под /usr и /opt, /home отдельно, tmpfs на /tmp и /var/tmp, можно даже попробовать squashfs, но с gzip.

CPU простаивает потому, что ждёт RAM. RAM достаточно медленная штука, если её долбить много, часто, и рандомно. А твой xz именно так и делает. Он и не распараллеливается, именно по этой причине - форк делали, но толку от него чуть.

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

правильно. Потому-то У ТЕБЯ в камень и в память не упирается. Но то у тебя.

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

я? УМВР.

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

форк делали, но толку от него чуть.

Ты про pxz? Прирост вполне себе показывает чуть менее, чем линейный.

На Windows тормоза понятны - загаживание и фрагментация реестра. А вот почему тормоза появляются в Linux - для меня загадка.

в линуксе тоже есть реестр. пруф

CPU простаивает потому, что ждёт RAM.

Ну и бре-ед. Потом не отнекивайся, что, мол, имел в виду другое.

здесь почитай: http://en.wikipedia.org/wiki/CPU_cache#Cache_miss

потом посмотри, сколько жрёт xz, даже при распаковке.

вот видишь? я угадал. А ты говоришь - не в теме.

Ну как бы это стандартная методика.

Кстати /var/tmp ты зря в память засунул

У меня в памяти только /var/tmp/portage, для ускорения сборки пакетов, у меня же gentoo, а вот /tmp весь в памяти.

ну я же объясняю - грубо говоря, это такой RAM диск, который сам разворачивается в память

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

Но вот на быстром HDD - не факт.

Как минимум получение списка файлов будет ускорено за счёт squashfs. Да и к тому же диске всё равно медленнее памяти.

/ - 1 Гб
/usr - 4-5 Гб
/var - 3-5 Гб
/opt - 2-4 Гб
/home - всё остальное

А потом он начал устанавливать софт… лол.

-O2 (или -O3 для отпетых ССЗБ и просто крутых хакеров).

Fixed.

тебе напрямую не проверить моё утверждение? Повторю:

Во первых, это не то утверждение. Ты сказал:

Да и запускаться ПО будет медленно. Но НЕ из-за фрагментации.

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

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

головой надо думать перед тем, как давать советы. Если-бы у ТСа был quad+8GbRAM+SSD, то у него никакой линукс бы не тормозил, даже убунта. А у него — тормозит.

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

а если диск таки быстрый? Откуда ты знаешь, какой там диск?

Я повторюсь ещё раз, надо головой думать применять рекомендации

повторяться не надо. Надо было сразу писать «если у вас quad…»

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

да. Было такое. И там было быстрее юзать диск напрямую. И ставить лёгкий WM, дабы освободить памяти, дабы был побольше дисковый кеш(что-бы на винт реже лазила). у тебя вот это не актуально, с твоим тормозным HDD, в него всё упирается, вот ты и перекладываешь дефектность своей системы на здоровые компоненты. Правильно делаешь. Хотя лучше и дешевле купить SSD, и тогда у тебя будет всё летать без всяких aufs. Но можно и так. А вот ТСу это вряд-ли поможет. Хотя - кто знает.

Но поверь и на более старом железе это даёт неплохой результат.

я же говорю: дело не в старости, а в несбалансированности. Своими рекомендациями ты просто смещаешь баланс. Это лучше делать при покупке, но можно и постфактум(хоть и хуже).

здесь почитай: http://en.wikipedia.org/wiki/CPU_cache#Cache_miss

Ну и что делает процессор, пока резолвится cache miss?

Ты про pxz? Прирост вполне себе показывает чуть менее, чем линейный.

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

в линуксе тоже есть реестр. пруф

это wine, а не линукс. Настоящий реестр есть в гноме (был, во всяком случае).

Debian, Xfce, ничего не тормозит. ЧЯДНТ?

Благодаря убунту-хейтерам нормального ответа ты не получишь.

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

У меня в памяти только /var/tmp/portage, для ускорения сборки пакетов

вот я и боюсь, что кто-нить засунет /var/tmp в память, а потом будет удивляться.

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

IRL она на диске, в памяти, и в кеше(тоже в памяти). Но не всё, конечно. Но много.

Как минимум получение списка файлов будет ускорено за счёт squashfs. Да и к тому же диске всё равно медленнее памяти.

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

Т.е. диск конечно твой squash не обгонит, однако этот squash может что-то нужное затормозить. Особенно если ядер 2, а не 4.

xz же на основе lzma2 собран, а оно поддерживает многопоток изначально.

Настоящий реестр есть в гноме (был, во всяком случае).

да, есть. просто сменил названий с gconf-editor на dconf-editor

но там все в xml хранится (как конфиги в венде), так что это только пародия на реестр

-O2 (или -O3 для отпетых ССЗБ и просто крутых хакеров).

Fixed.

с -O3 я да, перестарался. Я только свои проги так собираю, и то в тестинге только.

Да и запускаться ПО будет медленно. Но НЕ из-за фрагментации.

Если ты это проверял, огласи методику.

берём систему которая обновляется уже давно, tar'им /usr, потом рас'tar'иваем на чистую ФС. По идее, должно быть быстрее. IRL - так же.

И выше эту методику я уже озвучивал ЕМНИП.

Ну и что делает процессор, пока резолвится cache miss?

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

вот я и боюсь, что кто-нить засунет /var/tmp в память, а потом будет удивляться.

Заметь ТС я этого не предлагал, но сообщением ранее я говорил, что нужно думать перед тем, как что-то делать. Кроме того есть опции монтирования tmpfs, которые определяют максимальный размер выделяемой памяти под tmpfs. Ну и нужно понимать сколько места в tmpfs потребуется задаче. Если задача требует много места, то в моём случае на /var/tmp/portage монтируется раздел или делается '-o bind' с файловой системы, что в общем-то одно и тоже, где много места.

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

Т.е. диск конечно твой squash не обгонит, однако этот squash может что-то нужное затормозить. Особенно если ядер 2, а не 4.

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

К тому же я не посоветовал ТС обязательно использовать squashfs и aufs, я лишь упомянул о них, как о дополнительной возможности. В основном мой совет - это более грамотно выносить части корневой файловой системы на отдельные разделы / файловые системы.