chromium из исходников
после пары-тройки часов компиляции сборка выжрала остатки памяти из 8 ГБ ОЗУ и ушла в медитацию по ворочанию оставшимися ресурсами

8 гигов - это еще цветочки. Там некоторые единицы транслции headless части сжирают 6-7 гб каждый при компиляции. Прикинь, если сразу в 8-16 процессов по 6 гигов.
Хотя во фри используется clang, он чуть менее требовательный к памяти, но тормоз.
Ungoogled + свои патчи для вырезания headless + патченный ninja, который следит за доступной памятью перед запуском задач, кое как решают эти пролемы.
Скоро интернет будет доступен только через блоб, генерируемый на топ 50 эвм.

Так-то 64гиг озу это четыре планки ddr4.

Две, если регистровой.

УМВР. На генте с дефолтом собираю в 5 потоков на 16 гигах ОЗУ. С учетом, что вся система кушает около 4-5 гиг, ни разу не видел, чтобы потребление памяти выходило за 8 гигабайт при сборке хрома. Собираю тормозным шлангом, да...

Раз на раз не приходится. Одного раза мне хватило. Теперь только через свой ninja, всегда (почти) доступно 4 гига памяти.

Смотря сколько Z-пулов в это время подключено. Каждый пул в процессе работы резервирует порядка 1 гигабайт ОЗУ. Кроме того, во время компиляции компьютером пользуешься как десктопом, что-то на нём делаешь - браузеру Firefox с открытыми несколькими вкладками уже 2 гигабайта мало.

(Обычная загрузка ОЗУ, например, у меня 2,5-3 ГБ, сечас подключено два пула: один системный, другой восстанавливается, в Firefox открыто 5-6 вкладок, ещё что-то запустишь и нету ~5 гигов, то есть больше половины ОЗУ при общем объёме 8 ГБ вряд ли хватит на что-то более-менее серьёзное. Поэтому на машину сборщика и тем более разработчика надо ставить как минимум 16 ГБ, а лучше 32, если нужна виртуализация).

Ну у меня 16 гиг ОЗУ. Правда, у меня еще ядрышко в системе со своим конфигом, там тоже кое-какие вещи твикаются по потреблению памяти. И у меня не фряха.

ядрышко в системе со своим конфигом, там тоже кое-какие вещи твикаются по потреблению памяти

Чушь.

Ну вообще не чушь, там хорошо так можно натвикать. Грепни справку по слову мемори.

Всё давно оптимизировано в релизных ядрах. Твиками можно выйти не далее чем 10% управлямых параметров, остальное ведёт к нестабильной работе. Так что лучше вложиться в железо, которое способно тянуть, а не заниматься ерундой на каком-нибудь i3 с 4ГБ ОЗУ и 12ГБ SWAP (для примера). Хотя, если этот SWAP будет находиться в NVMe SSD или HBM...

Скажем так, у меня релизное ядро. Я говорю о конфигурации ядра, читай об опциях его сборки. И да, там можно изменить поведение системы в некоторых границах по вкусу. Например, включить и настроить CMA так, как хочется. Изменить сжатие ядра, заставить его сжимать модули при инсталляции, или наоборот. Можно включить API для сжатых страниц в памяти, можно выключить. Мне вот KSM нужен, я виртуалками балуюсь. Другое дело, что вы этим можете и не пользоваться, но это уже ваши проблемы. Система отлично влезает в 8 Гб ОЗУ, больше удаётся занять только специфичными задачами. И браузеры у меня открыты, и всего остального открыто тоже дай бог. Разница в потреблении ресурсов до 30% может достигать, если хорошо красноглазить, но нормальным людям не до этого. Ну и 10-15% памяти это при 4 гигах 400-600 М ОЗУ. Тоже весьма ощутимо.

hugepages при меньше 16 не включишь

Я про них не говорил. Но вообще, на малом объеме памяти смысла в их включении нет. CMA - continuous memory allocator - это другое. Упс. Посмотрел, кстати. У меня UMA буфер занимает 512 метров, так что фактически памяти у меня меньше, чем 16 гиг, а hugepages включены. Такие дела.

на i7 4790k в режиме -j4 сборка firefox 60 заняла минут 40, но у него и частота 4 GHz и выше, и стоит он дороже заметно, в отличие от. Тем кто скажет, что за 20 минут он собирается на core i3 2010 года, можешь плюнуть в рожу.

Кукурузен такой кукурузен.

А если c l1tf=off nopti nospectre_v2 nospec_store_bypass_disable в параметрах ядра?

И почему не -j8 ?

сборка выжрала остатки памяти

А во фре есть сжатая память/своп?

то ничего - у меня старое ядро, до появления этих патчей

-j4 , потому что вот так в данном случае

Есть.

И даже с нею 8 гигов на хром не хватает? Оо

Хватает.

Есть.

Угребищный костыль с ZFS-сжатием не считается.

на i7 4790k в режиме -j4 сборка firefox 60 заняла минут 40

Последний ESR до 60 версии, без растов и прочих — тоже 40 минут, но на 2 ядрах i5 520m ноута с 8ГБ ОЗУ (под сборку выделялся tmpfs на 5ГБ).

ЗЫ: надеюсь для тех, кто придумал эту капчу, в аду припасен отдельный котел.

а чё без ссд или у тебя tmpfs? какие юзы? custon-cflags включен, что в них? то, что у тебя в 2 раза дольше сборка занимает, при том, что процессор в 5 раз дороже, вероятно указывает на несостоятельность сравнения.

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

ядро как ядро, без ssd, gentoo в vbox (поэтому и -j4), флаги никакие не включены дополнительные.

Но даже на 4 «ядрах» он собирает gcc-7.3 и llvm-6.0.1 в 2 раза быстрее, чем core i3 550 на реальном железе.

В смысле без растов и прочих? Сам firefox собирается посредством rust естественно.

поменяй юзерагент на андроид — станет гораздо лучше

лови:

Mozilla/5.0 (Linux; Android 7.0; PLUS Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.98 Mobile Safari/537.36

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

В виртуалке (тем более в коробке), без заботливо с любовью настроенной системы не щитово, твои показатели сильно хуже тех, что должны быть. Вот раст довольно долго компилируется и по 20 гигов на диске занимает, видимо у вебкита учились. А жирнолис раньше ~15 минут компилировался, теперь ~30 (и это со всеми патчами против спектры на старом процессоре).

Кстати венда с включёнными патчами от спектры и мельтдауна стабильно показывает более высокую производительность, чем с отключёнными. Может и у линукса где-то так же? Что они там измеряли и когда? Может там баги были?

твои показатели сильно хуже тех, что должны быть

Ну и какие должны быть на реальном железе для -j4 ?

Вот раст довольно долго компилируется и по 20 гигов на диске занимает

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

Не, на 7 гигах он обламывается регулярно, да и на 10 вроде тоже — там что-то около 12 надо было. Теперь надо следить, чтобы более 15, на диске, на котором он будет собираться, было свободно. Было очень удивительно, что это даже больше чем у всех неудачных экспериментов с lto у браузеров и багованных гцц. Аппетиты жирнолиса кстати тоже зависят от параметров сборки.

Раст собирается дольше гццшного тулчейна и это фейл какой-то. У джавы что ли учились?

-j4

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

Не, на 7 гигах он обламывается регулярно, да и на 10 вроде тоже — там что-то около 12 надо было.

ещё раз, у меня сегодня было свободно не больше 7

а чё бы не -j5

потому, что для vbox я всего 4 отдал.

Вот atlas собирался в коробке 3 часа, а дома 10 минут, потому что он самооптимизацией занимается большую часть времени сборки и самотестированием. Что-то ему в виртуалке не удаётся быстро соптимизировать.

Разгоном... В смысле, регулировкой (повышением) напряжения. Ясно. Запомню, спасибо.

Ну так для лучших результатов отключить SMT и nproc+1 c запуском дополнительных мержей в зависимости от загруженности — всегда работает.

свободно не больше 7

как это возможно? может у тебя бинарный?

в виртуалке

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

в vbox

Nuff said. Дальше выяснится что ты его андерклокнул до 2ггц, стоит одна планка памяти и ещё какие-нибудь упоротые подробности.

уже выяснилось, что и при текущих настройках он собирает софт в 2 быстрее чем недорогой i3 2010 года.

не знаю как возможно, но бинарного раст в генте я не помню. версия 1.28, кажется. Может новые хотят побольше.

Последний ESR до 60 версии, без растов и прочих

52-й то есть? Его может без раст собрать и можно ещё было, но вот 60 в генте его тащит в обязательном порядке, так что сравнивать тут нечего.

52-й то есть? Его может без раст собрать и можно ещё было, но вот 60 в генте его тащит в обязательном порядке, так что сравнивать тут нечего.

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

А в чём соль этого хрюста, если собиратся медленнее крестов а тормозит больше?

поменяй юзерагент на андроид — станет гораздо лучше

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

А в чём соль этого хрюста, если собиратся медленнее крестов а тормозит больше?

А в чем соль этого овновеба, если требуются браузеры, по количеству строк кода (причем, частью в разы высокоуровнее Си) сравнимые с ядром пингвина?

Архив с бинарным пакетом webkit2-gtk3-2.20.5.txz собрался за 37 минут. При 100% загрузке в 12 потоков. При этом я спокойно смотрел Youtube-ролик в FullHD 1080p50 в Firefox (с программным декодированием видео), не замечая процесса сборки. Потребление памяти при этом 6,3 ГБ.

не замечая процесса сборки

Это и на днищефеноме каком-нибудь так же бы было. Лагает только от всяких 12309 и кончающейся памяти, ну или если у тебя совсем пень4 какой-нибудь.

Гугл считает, что я ботнет (вполне заслуженно) и не показывает поиск (совсем, иногда капчу предлагает), но переводчик и капчи работают. Я имею в виду, разница между агентом сафари и андроида слишком заметна, для андроида максимум 2 раза ввести капчу и все разгадываемые.

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

А смена -j4 на -j8 в лучшем случае даст ~15% прироста скорости сборки. Эту зависимость роста производительности можно начиная с какого-то момента аппроксимировать линейной, но коэффициент будет далеко не 1

Сразу же после сборки запустил процесс обновления thunderbird/ Итог (смотрим на время окончания):

===>>> The following actions were performed:
	Upgrade of thunderbird-60.1.0_2 to thunderbird-60.2.1
	Upgrade of thunderbird-i18n-60.1.0 to thunderbird-i18n-60.2.1

[04.10.2018][13:53:37]

Снял iostat во время компиляции thunderbird.

На SSD Crucial M4 64GB:

% iostat -w 10 ada0
       tty            ada0             cpu
 tin  tout  KB/t tps  MB/s  us ni sy in id
   0  2155 34.25   7  0.24   1 13  2  0 84
   0  1110 19.04  12  0.22   0 94  6  0  0
   0  1215 20.56  12  0.24   1 94  5  0  0
   0  3013 19.79  13  0.26   0 93  6  0  0
   0  1144 19.38  11  0.21   0 94  6  0  0
   0  2386 23.13   6  0.13   0 92  8  0  0
   0   736 19.44  13  0.25   1 94  5  0  0
   0  1990 15.81  15  0.23   0 94  6  0  0
   0  1504 24.88  11  0.26   0 93  6  0  0
   0   787 16.07  12  0.19   0 94  6  0  0
   0  1240 21.38  11  0.22   0 93  6  0  0
   0   290 16.75   6  0.10   0 95  5  0  0
   0   729 25.57   5  0.13   0 96  4  0  0
   0   556 18.27  12  0.21   0 96  3  0  0
   0   862 40.61  15  0.60   0 94  6  0  0
   0   296 13.80   5  0.07   0 96  4  0  0
   0   271 19.43  11  0.21   0 97  3  0  0
   0  1318 24.54  14  0.34   0 95  5  0  0
   0   962 65.18  25  1.58   0 91  6  0  2
   0  1052 16.37  13  0.21   0 86  5  0  9
   0  1251 20.37  12  0.24   0 94  5  0  0
   0  1209 19.06  13  0.24   0 94  6  0  0

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

Ну, у меня все не так страшно, хотя при усиленном поиске капчу выдает даже на домашний адрес, c мягким и ненавязчивым предолжением перейти на сторону «не злых» с их печенюшками.

Тут другое - гугл (как обычно) после подсадки всех на свою реализацию капчи, вконец оборзел. Если ранее можно было прочитать и ввести два слова за десяток секунд, то теперь подгрузка отдельной части-картинки с автобусом-мотоциклом занимает в лучшем случае 7-8 секунд (специально засек) из-за гребаной «плавной» анимации-перехода.
Кончились картинки с мотоциклами на на экране - переходим к следущей угадайке
Теперь прохождение гуглокапчи стабильно занимает полторы минуты (или как сейчас - 1:50). Токен живет минуты две-три (не засекал), повторное прохождение при этом никак не облегчается/уменьшается. Не говоря о том, что разгадка капчи — отличная возможность деанонимизации по характерным движениям мышки
И это все — не из под tor или прокси с vpn-ами. В общем: «Internet is dead! Long live GoogleNet!»

Хотел спросить, второй поток на ядро отключается в биос? То есть есть ли возможность в биос отключить это как это делается для HT для intel?

я один раз видел, как один мужик минут 15 боролся с гугл-капчей. Он был очень настойчиво и победил. А гуглу, наверное, не нравилась скорость с которой выбирались правильные варианты - щёлкал он достаточно быстро и правильно.

Ryzen 2600X. Всё в порядке.