Форум проекта PuppyRus Linux
Разработки проекта PuppyRus => Программирование и компиляция => Компиляция ядра Linux => Тема начата: sfs от 30 Май 2019, 16:55:20
-
Для компиляции 5.15 ядра необходимо 22гб места на диске (выбирайте самый быстрый)
На 4x ядерном i3 3,4Ghz компилится 2-2,5 часа (зависит от используемого конфига). На ssd быстрее
Параметры конфига ядра (https://cateee.net/lkddb/web-lkddb/) : https://www.kernelconfig.io/
Монолитное ядро. Скрипт преобразования любого конфига (https://forum.puppyrus.org/index.php?topic=23523.msg178736#msg178736)
https://wiki.gentoo.org/wiki/Kernel/Configuration/ru
http://file.puppyrus.org/users/pra/kernel/cfg.tar.gz - все конфиги
vmlinus*-porteus сопоставимых версий меньше нашего vmlinus*-pf (от Pro) на 1,8 мб
И 000*.pfs больше на 4мб
При этом кажется , что и система с porteus грузится быстрее
Может компилить pf ядра с porteus конфигом... Заодно для i686 добавить PAE (в конфиге , в аттаче , вроде, уже появился
Скомпилил : ftp://ftp.yandex.ru/puppyrus/puppyrus-a/kernel/new/5.1.4-pp-drv Итог
неудачный (http://forum.puppyrus.org/index.php?topic=21774.msg172298#msg172298)
-
важна надежность работы, "безглючность" ( для меня )
что выбрать не знаю, пользуюсь тем что дали :)
размер плюс минус несколько мб не так важен( опять же только для меня )
-
важна надежность работы, "безглючность" размер плюс минус несколько мб не так важен
Тогда для Вас - донорские. Наши тестируются плохо и я не считаю себя спецом в области ядра
Дядя Шурик - проголосовали за пф - можете обосновать кроме "родное"?
-
сделать гибрид porteus+pf
- сделал, проголосовал
Размер - как у портеус (т.е. меньше пра) - хорошо бы понять за счет чего
Выложу на неделе. Дрова придется перекомпилять
-
ftp://ftp.yandex.ru/puppyrus/puppyrus-a/kernel/new/5.1.4-pp-drv
Если проблем не выявим - пойдет в пра03 и ддр
-
Если проблем не выявим
пока нормально, ничего не отвалилось
-
Если проблем не выявим
Выявил:
1. Не понимает initrd.lz - и не надо . Ядро меньше
2. Не понимает codepage=866 при монтировании в инитрд fat. Надо убрать codepage и iocharset= в 81 строке linuxrc (initrd.xz) - выложу поправленный
Поэтому не грузится с фат. Здесь оно и не нужно. В системе на фат с русским норм
-
выложу поправленный
initrd.xz (ftp://ftp.yandex.ru/puppyrus/puppyrus-a/kernel/initrd.xz) - универсальный для pra и ддр. Теперь грузит pfs sfs xzm
прочие инитрд переложил (ftp://ftp.yandex.ru/puppyrus/puppyrus-a/kernel)
Пока не обновил скрипт fix - будет выдавать, что initrd устарел. Игнорируйте
-
Случайно натолкнулся - в porteus нет zstd (http://forum.puppyrus.org/index.php?topic=21412.msg154788#msg154788) . Вроде по итогу этой темы пришли к выводу - нет смысла заморачиваться. Т.е. жалеть не о чем
Там, похоже вообще все по минимуму. Зато и размер соответствующий
По максимуму в manjaro
А pf от Pro где-то посередине. Нужна ли кому-то именно "середина"
Если определим, что в конфиге портеус нет нужного нам - можно добавить и перекомпилить
Только надо определиться - что именно...
-
Если проблем не выявим
Выявил:
1. Не понимает initrd.lz - и не надо . Ядро меньше
2. Не понимает codepage=866 при монтировании в инитрд fat. Надо убрать codepage и iocharset= в 81 строке linuxrc (initrd.xz) - выложу поправленный
Поэтому не грузится с фат. Здесь оно и не нужно. В системе на фат с русским норм
Не понятно, как монтирование работает :)
С новым initrd.xz и ядром 5.1.7 в DDR и с 5.1.4 в PRA64 19.04 загружается с флешки FAT32 и работает,но вопросики вместо русских букв на флэшке с FAT32, а если отключить флешку и потом подключить изменённым mount-wizard , то
видно русские буквы.
в mount-wizard в строке 14 вот такое надо бы добавить:
MOPT="-o umask=000,iocharset=utf8,codepage=866,shortname=mixed"
ext4 с русским буквами тоже им подключается нормально
-
в mount-wizard в строке 14 вот такое надо бы добавить:
MOPT="-o umask=000,iocharset=utf8,codepage=866,shortname=mixed"
Он и так с этими ключами монтирует. Сами же пишите
если отключить флешку и потом подключить изменённым mount-wizard , то
видно русские буквы.
Не видно их, т.к. смонтировано без codepage=866 на стадии инитрд
Из идей - уже в системе перемонтировать с этими ключами при загрузке системы... А получится ли если fat раздел загрузочный...
Есть идеи лучше?
-
в mount-wizard в строке 14 вот такое надо бы добавить:
MOPT="-o umask=000,iocharset=utf8,codepage=866,shortname=mixed"
Он и так с этими ключами монтирует. Сами же пишите
если отключить флешку и потом подключить изменённым mount-wizard , то
видно русские буквы.
Это только у меня так, с изменённым вручную mount-wizard, а у других пользователей в стандартном
mount-wizard таких ключей нет, там 14 строка такая:
MOPT="-o umask=000"
со старыми ядрами 4.х и старым инитрд монтировались флэшки с полным набором ключей, хотя в mount-wizard только umask=000.
а с ядрами 5.х и новым инитрд не работает, пока вручную не исправишь, но при этом spacefm - по прежнему монтирует с вопросиками вместо букв
Не видно их, т.к. смонтировано без codepage=866 на стадии инитрд
да , сразу после загрузки с флэшки, если эта флэшка смонтировалась ,то вопросики.
а в некоторых пра, она отмонтируется при загрузке.
Отчего это зависит?
Из идей - уже в системе перемонтировать с этими ключами при загрузке системы... А получится ли если fat раздел загрузочный...
Есть идеи лучше?
ну это же только к одной будет применимо, а если потом другую флешку вставить и в spacefm она опять будет с вопросами, а если монтировать изменённым mount-wizard, то русские буквы, но только у меня :) , поэтому и предлагаю добавить в 14 строку ключи.
А то не хочется возвращаться на ядра 4.х - там страшные уязвимости :)
P.S. И ядро 5.2 тоже пока не надо - похоже в него закладку вставили:
https://www.opennet.ru/opennews/art.shtml?num=51051
цитаты оттуда:
Добавлена поддержка электронной цифровой подписи по ГОСТ Р 34.10-2012 (RFC 7091, ISO/IEC 14888-3), разработанная Виталием Чикуновым из "Базальт СПО". Во встроенную реализацию TLS добавлена поддержка AES128-CCM. В модуль crypto_simd добавлена поддержка алгоритмов AEAD;
А можно мне в будущий апдейт манжары и федоры отключить вот это?
Добавлена поддержка эллиптических кривых GOST R 34.10-2012 (RFC 7091, ISO/IEC 14888-3).
КАТЕГОРИЧЕСКИ ПРОТЕСТУЮ!
2.32, Аноним (-), 12:50, 08/07/2019 [^] [^^] [^^^] [ответить]
+2 +/–
Чем оно тебе мешает? Просто не используй.
3.34, Fyjybv755 (?), 12:52, 08/07/2019 [^] [^^] [^^^] [ответить]
+8 +/–
От одного факта наличия в ядре этого кода сало подгорать начинает.
3.100, хотел спросить (?), 07:33, 09/07/2019 [^] [^^] [^^^] [ответить]
+/–
этот тот который с бэкдором?
> Researchers have identified a possible backdoor in the Grasshopper and Stribog algorithms
категорически удваиваю.
-
ftp://ftp.yandex.ru/puppyrus/puppyrus-a/kernel/new/5.1.4-pp-drv
Если проблем не выявим - пойдет в и ддр
Еще выявил. Не работает radeon (http://forum.puppyrus.org/index.php?topic=19443.msg126213#msg126213) ,т.е. на ATI видяхах разрешение экрана маленькое и не увеличить
В ftp://ftp.yandex.ru/puppyrus/puppyrus-a/kernel/new/5.1.4-pf-drv/ - норм
Буду менять это ядро в ddr
Почему так не разбирался
Скомпилил 5.11-pf2 (https://forum.puppyrus.org/index.php?topic=14803.msg176197#msg176197) со свежим porteus конфигом - пока норм
-
Скомпилил 5.11-pf2 со свежим porteus конфигом - пока норм
zswap монолитно. zram модулем. Может понадобиться в свете этой (https://forum.puppyrus.org/index.php?topic=23160.msg176484#msg176484) темы
-
http://www.pivpav.com/post/150#comment-1540230756
https://wiki.archlinux.org/index.php/Zswap
оба можно модулем. На стадии инитрд они не нужны. Можно позже (в загруженной системе) с ними разобраться
-
Скомпилил. Конфиг от porteus 5.10
Технология не отработана. Некоторые штуки, задуманные автором pf-linux, не попали в ядро. В частности BBR, может еще что....
Включение TCP BBR ускоряем сеть в Ubuntu Linux (https://www.k7d.ru/linux/vklyuchenie-tcp-bbr-uskoryaem-set-v-ubuntu-linux/)
Посложнее Система BBR: регулирование заторов непосредственно по заторам (https://habr.com/ru/post/322430/)
File config_arch_generic of Package linux-pf-generic (https://build.opensuse.org/package/view_file/home:post-factum:kernels/linux-pf-generic/config_arch_generic?expand=1)
https://gitlab.com/post-factum/pf-kernel/-/wikis/README
-
Технология компиляции ядра отработана. PKGBUILD выложен
Несколько недоработана сборка доп. компонентов (видеодрова и т.п.) и они не проверяются
Получается придется компилить самому
Предлагаю здесь обсудить конфиг и патчи
Сейчас
Цитата: sfs от 07 Март 2021, 11:18:02
Конфиг от porteus 5.10
config.x86_64
Конфиг надо отработать. Сравнить от Pro porteus pf и сделать оптимальный свой
Т.е. скриптами (пока не написаны) распарсить конфиг на то что включено - решить что монолитно
Планирую этим заняться но очень не скоро. Не успеваю с имеющимися дистрибами
Подключайтесь - советами и скриптами помогу. Ну или хотя бы постите параметры из конфига - которые надо не упустить
-
https://aur.archlinux.org/packages/linux-mini/
-
У 5.11.0-pf2-1-pra есть плюс который кроет все минусы : aufs+uksmd . Этого сочетания нигде не спереть. Только самим компилить.
uksmd по цифрам очень эффективен. У меня ram везде от 4пб. Интересно - как он на 1-2 гб...
собирать ядра от одного автора, используя полный конфиг от другого... Наверно не лучшая идея.
Цитата: sfs от Сегодня в 15:40:52
При компиляции 5.11.0-pf2-1-pra я использовал конфиг от 5.10porteus
Если взять конфиг от автора pf = большое ядро без aufs
porteus взял полу-случайно - первый под руку попался + самый свежий из маленьких проверенных
С конфигом надо разбираться. Планирую, но не скоро
-
Вот пример из AUR linux-pf (https://aur.archlinux.org/packages/linux-pf/), где сборщик аккуратно добавляет свои настройки через pf_defconfig (https://aur.archlinux.org/cgit/aur.git/tree/pf_defconfig?h=linux-pf).
Вот пример сборки aufs-ядра linux-aufs (https://aur.archlinux.org/packages/linux-aufs/).
Кстати, все PKGBUILD по ссылкам позволяют гибко настраивать их под себя, свое железо.
-
С PKGBUILD (https://mirror.yandex.ru/puppyrus/puppyrus-a64/kernel/new/5.11.0-pf2-1-pra/PKGBUILD) проблем нет. Проблема что я не особо шарю в конфиге ядра
Я Вам уже предлагал заняться сравнением конфигов и скомпилить
Наверное надо оталкиваться от конфига Pro + сравнить со свежим от автора pf и компилить LTS ядро
За суперсвежаком тут гоняться смысла нет (если не появится что-то новое нужное нам типа горячего подключения overlayfs)
-
все дело в ядре 000-kernel-5.11.0-pf2-1-pra_64.pfs и le9-patch, о котором писал здесь.
Эту фишку уже несколько раз дорабатывали, так что есть резон пересобрать ядро с новыми патчами. Глядишь, пользователи линукс совсем забудут явление, когда система встает 'колом', пытаясь сбросить кеш в медленный своп.
Дебаты разрабов закончились 21.02, а я компилил 5.11.0-pf2-1-pra 21.03, т.е. скорее всего le9-patch внутри
Попробовал поискать что-то похожее на https://github.com/hakavlad/le9-patch/tree/main/le9db_patches в https://github.com/pfactum/pf-kernel/compare/v5.12...v5.12-pf6.diff - не нашел, но в списке фич (https://gitlab.com/post-factum/pf-kernel/-/wikis/README#ok-whats-there-in-your-patchset) есть
-
скорее всего le9-patch внутри
Что значит скорее всего. :) Я вообще-то написал не в качестве предположения, а утверждения. )
все дело в ядре 000-kernel-5.11.0-pf2-1-pra_64.pfs и le9-patch
Специально вчера заходил на gitlab и проверял:
Выпуск v5.11-pf2: v5.11-pf2 * исправления Arch Linux были объединены * применены исправления zswap * обновлено исправление сброса * улучшен стиль кода защиты файловых страниц
Но с тех пор этот патч еще несколько раз дорабатывали, поэтому и написал, что имеет резон пересобрать с новыми патчами.
v5.11-pf7 выпуск: v5.11-pf7 * ядро обновлено до v5.11.14 * драйвер NTFS3 обновлен до версии 26 * требования к версии GCC для Zen 3 были снижены * выбран асинхронный код распаковки initramfs * защита файловых сопоставлений была улучшена, чтобы не защищать грязные страницы * патчи Arch Linux были повторно синхронизированы
-
Скомпилил http://mirror.yandex.ru/puppyrus/puppyrus-a64/kernel/new/5.12.0-pf6-lf
Вдохновлялся https://build.opensuse.org/package/show/home:post-factum:kernels/linux-pf-generic
Конфиг от Pro https://mirror.yandex.ru/puppyrus/puppyrus-a64/kernel/0ld-02/4.20.15-pf7_64/linux_headers-4.20.15-pf7_64.pfs
На это (https://forum.puppyrus.org/index.php?topic=23423.msg177383#msg177383) не тестировал
Компилить пришлось на lfa full , обновленном до свежего. Нужен свежий gcc и пр. обвязка
Проблема, затронутая в этой теме, становится неактуальной с ядром 5.12.0-pf6-lf. В нем пофиксили явление, когда копирование большого файла идет сначала бодро, затем скорость падает почти до нуля и все это тянется длительное время.
-
Скомпилил
Поздравляю! На этот раз на Richy64 Ok!
-
На этот раз на Richy64 Ok!
У всех так? А на старом железе?
В чем была проблема с 511 у меня теорий нет. Т.е. что дало улучшений - версия ядра, версия pf патча или конфиг от портеуса...
Глубоким анализом конфига (https://mirror.yandex.ru/puppyrus/puppyrus-a64/kernel/new/5.12.0-pf6-lf/PKGBUILD/config_arch_generic) я так и не занялся. Тупо взял старый от Pro.
Можно посравнивать с тем, что на https://build.opensuse.org/package/view_file/home:post-factum:kernels/linux-pf-generic/config_arch_generic?expand=1 компилят. Автор этим занимается или кто-то другой - я не знаю
Можно сейчас заняться, но у меня особых идей нет
Жду предложений до понедельника. Если не будет - докомпилю дрова и пойдет во все исо
-
ядра (kernel) от Xanmod можно как-то в дефолтную сборку включать? Очень не хватает скорости работы -> https://xanmod.org/
Унас используются pf-kernel (https://gitlab.com/post-factum/pf-kernel/-/wikis/README), тоже считаются быстрыми.
Насколько мне известно почти все патчи xanmod есть и в pf. Причем в pf больше функционала. Например собственная реализация uksm
Если чего-то нет- пишите - при следующей компиляции ядра попробую добавить
А вообще тема кастомных ядер спорная. На совсем старом железе чудес не будет. Скорее всего удастся получить какие-то хорошие показвтели "в попугаях" и убедить себя что стало быстрее
Можно поискать xanmod ядро с aufs и сделать модуль. Есть желающие тестировать?
-
Для i686 ядер с le9-patch у нас нет.
В aur (https://aur.archlinux.org/packages/linux-pf/) PKGBUILD с arch=('i686' 'x86_64') от Thaodan. Версии запаздывают (https://gitlab.com/Thaodan/linux-pf), плюс для i686 и x86_64 они разные (скрин). Но учитывая инфу (https://github.com/hakavlad/le9-patch#how-to-get-it), le9 успел попасть в оба варианта. Если только искуственно не вырезан.
pf-kernel обеспечивает защиту файловых страниц (с собственной реализацией le9) по умолчанию, начиная с v5.10-pf2;
Брать для x86_64 не выгодно, многие фиксы туда не попали и наше 5.12.0-pf6-lf всяко будет впереди планеты всей. А вот для i686 сгодится...
-
для i686 и x86_64 они разные
Сравнил в mc. Впечатление, что 64 дорабатывали, а 32 подзабросили. Местами в когфиге есть указания на 32 и 64 соответственно. Возможно такое автоподправится в процессе автоконфигурации
Хорошо бы найти хоть какое-то ядро с le9, чтобы понять - есть смысл компилить 32 или нет...
Брать конфиги из aur нам не подойдет. Не получится юзать без пересборки инитрд
В идеале надо проанализировать конфиги от Pro и porteus на предмет включенного монолитно и сделать скрипт, который любой конфиг приводит к такому виду
-
Может и время ядер пришло? Тема с лора Собирайте своё ядро clang'ом!
Для нас вряд ли. Раньше чем это будет в AUR. Нет у нас спецов по ядру уровня таких задач. Не очень представляю как можно сравнить 2 ядра скомпиленных разным способом. Т.е. даже если сделаем - как выбрать...
У нас более простые задачи. Нам бы сравнить конфиги и сделать скрипт который делает монолитное ядро из любого конфига. Т.е. переводит модули ядра в монолит, чтобы не таскать в инитрд udev
Ну и последнее мое ядро вроде всех устроило. Вряд ли появится что-то прорывное. Можно на нем сидеть пару лет
-
Раньше чем это будет в AUR.
AUR (https://aur.archlinux.org/packages/?O=0&K=clang+linux)
Сборка ядра Linux 5.12.12 c LLVM 12 + Clang и LTO оптимизацией (https://habr.com/ru/company/ruvds/blog/561286/)
Собирайте своё ядро clang'ом! (https://www.linux.org.ru/forum/general/15667835)
Но раз спецов у нас нет, что ж поделаешь. )
upd. Перенес сюда ссылку с лора, чтобы все в одном месте было.
-
release: v5.13-pf4
* the kernel has been updated to v5.13.8
* the proactive compaction optimisations have been applied
* the NTFS3 driver has been updated to the submission v27
* the v4l2loopback driver has been updated to the latest stable git HEAD
https://gitlab.com/post-factum/pf-kernel/-/tags/v5.13-pf4
Какая-то новая фишка? Если правильно понял, что-то связанное с фрагментацией памяти.
-
the proactive compaction optimisations have been applied
Видимо это (https://lwn.net/Articles/717656/)
Одна из целей уплотнения памяти, сказал Властимил Бабка в начале своего сеанса отслеживания управления памятью на саммите Linux Storage, Filesystem и Memory-Management Summit 2017, состоит в том, чтобы сделать страницы более высокого порядка доступными. Эти страницы - соответственно выровненные группы физически смежных страниц - имеют множество применений, включая поддержку функции прозрачных огромных страниц. В настоящее время уплотнение в основном выполняется по запросу в ядре; вместо этого он хотел бы сделать больше раньше времени.
Многие приложения значительно выигрывают от использования огромных страниц. Однако при выделении огромных страниц часто возникают большие задержки или даже сбой в условиях фрагментированной памяти. Упреждающее сжатие может обеспечить эффективное решение этих проблем, выполняя сжатие памяти в фоновом режиме. Благодаря предлагаемой мной реализации упреждающего сжатия типичные задержки выделения огромных страниц сокращаются в 70-80 раз при минимальных накладных расходах ЦП.
-
В свежих pf ядрах ntfs3 есть. Я не знал об этом. Не включил в конфиге.
Учитывая, что он заявлен уже давно в pf и инфа показана на главной странице (https://gitlab.com/post-factum/pf-kernel/-/wikis/README#ok-whats-there-in-your-patchset), можно сделать вывод о непродуманной сборке, :) когда отсекаются важные вещи, о чем я уже писал ранее (https://forum.puppyrus.org/index.php?topic=21774.msg176535#msg176535).
Конфиг надо отработать. Сравнить от Pro porteus pf и сделать оптимальный свой
Думаю алгоритм такой. Скачиваем https://www.kernel.org/pub/linux/kernel/v5.x/linux-5.13.tar.xz, выполняем make menuconfig, получая файл config. Далее сравниваем с config (https://build.opensuse.org/package/view_file/home:post-factum:kernels/linux-pf-generic/config_arch_generic?expand=1) от pf-kernel, отмечая изменения внесенные post-factum, назовем их diff-pf-config. (Может есть способ проще, как отметить все внесенные изменения автором патча в дефолтный конфиг ядра Linux?)
И уже потом прореживаем, отталкиваясь от конфига Pro, но помня о приоритете diff-pf-config. Тем самым удастся сохранить и не выключить все новые оптимизации pf, о которых еще не знал Pro, почему их и нет в его конфигах.
Надеюсь смог доступно донести идею. )
upd. Может все еще проще и достаточно будет применить этот diff-pf-config к конфигу Pro.
-
можно сделать вывод о непродуманной сборке
Ну так именно подобные темы я и имел ввиду, когда говорил что по ядрам я не спец
отсекаются важные вещи
Ну так тема про компиляцию ядра и была создана, чтобы народ писал про то что надо добавить. Как видите активности там нет.
Может все еще проще и достаточно будет применить этот diff-pf-config к конфигу Pro.
Думаю, проще сделать наоборот.
сравнить конфиги и сделать скрипт который делает монолитное ядро из любого конфига. Т.е. переводит модули ядра в монолит, чтобы не таскать в инитрд udev
Готовы заняться? Там grep+sed будет достаточно . С синтаксисом помогу
-
по ядрам я не спец
Готовы заняться?
А вот я то, конечно, еще тот спец. :)
-
Эта задача требует только знания bash
-
Да, знания bash это ко мне. :)
Я всего лишь выразил мнение, что нет большого смысла собирать новые ядра pf, если по факту все новые оптимизации, задуманные автором патча, остаются на уровне тех годов, когда ядра собирал еще Pro, учитывая что применяются его устаревшие конфиги.
-
нет большого смысла собирать новые ядра pf
Тогда бы не было uksmd+aufs ядер. Pro 5x ядра уже не собирал
aufs все посливали. Компилить придется самим
новые оптимизации, задуманные автором патча
Надо их хотя бы отслеживать
-
Наткнулся на интересную статью по ссылке с арчвики:
Arch Linux, стремящийся использовать LTO по умолчанию, возможно, повысит требования к x86-64 (https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-LTO-Proposed)
Здесь и про LTO оптимизации, которые думают применять дефолтно в арче и которые уже применяют в некоторых дистрибутивах или только собираются применять в других.
И про выбор уровней архитектуры x86-64, которые уже применяются в pf-ядрах, в бинарных (https://gitlab.com/post-factum/pf-kernel/-/wikis/README#but-i-want-binary-builds) пакетах.
Добавлена поддержка флагов "-march=x86-64-v[234]" для выбора уровней архитектуры x86-64 (v2 - охватывает расширения SSE4.2, SSSE3, POPCNT и CMPXCHG16B; v3 - AVX2 и MOVBE; v4 - AVX-512).
В догонку, Разработчики Arch Linux обсуждают идею предоставления порта x86-64-v3 (https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-x86-64-v3-Port-RFC).
Т.е. отказались от идеи дефолтно повышать требования к железу, будет выбор какие пакеты ставить.
p.s. Думаю, мой проц вписывается в x86_64_v2, но не факт:
live@roll2103 ~ % inxi -Cxxx
CPU: Quad core Intel Xeon E5450 (-MT-MCP-) arch: Penryn rev.10 cache: 6144 KB
flags: (lm nx sse sse2 sse3 sse4_1 ssse3 vmx) bmips: 25181
clock speeds: min/max: 1998/2997 MHz 1: 2098 MHz 2: 1998 MHz 3: 1998 MHz
4: 1998 MHz
-
Добавил в шапку какие фичи добавлены в какие версии pf-kernel
-
Протестировал 32 битные ядра на ноутах 2008 и 2005 года (1 ядро pentium m 1500 mhz 500mb RAM) - 414 и 513 (https://forum.puppyrus.org/index.php?topic=23523.msg178777#msg178777) на обоих запустились.
414 показалось помедленнее.
-
iwd на prar2110 c https://aur.archlinux.org/packages/iwdgui/ и ядром 5.7manjaro (в моих ядрах нет нужных ему компонентов)
Надо будет на перспективу при перекомпиляции ядра добавить нужное iwd
Пока обновления ядра не планирую
-
меленький отчет по ядру 5.13-pf-lf которое в iso:
1. Ноутбук lenovo, проц intel i5-7200 - не работает тачпад (откатился на 5.11 ядро
Спасибо +
https://forum.puppyrus.org/index.php?topic=23601.0
Похоже - зависит от версии ядра. Самое простое - откатываться на рабочую
2. Ноутбук asus, проц i7-2400 видео встроенное+ nvidia 720 - на экране все в мелкие разноцветные пиксели, nomodeset не пробовал (откатился на 5.4 ядро)
какой видеодрайвер использован?
3. Стационарный комп HP с интерированной графикой интел - черный экран с мигающим курсором в углу (откатился на 5.4)
На 5.4 откатывался потому что у меня для него есть свежий vbox а он мне нужен.
какой видеодрайвер использован? modeset или intel ?
Как у остальных?
У меня нигде пока проблем не возникло с этим ядром. Пробовал и на стационарах и на ноутах
-
Драйвер использован тот, который дефолтом в iso. Никаких настроек не делалось в xorg
-
Без перечисленного железа помочь можно только советами. Надо хотя бы понять заменой - где проблема в версии ядра или в видеодровах. Другие линуксы на этих пк без проблем?
-
Без перечисленного железа помочь можно только советами.
мне не нужны советы, я сообщил что нашел.
мог бы и не сообщать (в следующий раз так и сделаю)
-
Лучше выкладывай сразу с решениями ;)
-
да пожалуйста, раз сам не видишь.
Вот тебе решение: ядро 5.13 - говно. и что ты сделаешь?
-
Попрошу тебя скомпилить хорошее, с iwd ;)
-
Да ядро то не причем, хоть 5.13, хоть любое другое. Все проблемы начинаются, когда бездумно подсовывается свой .config при компиляции.
Если собирать по конфигу post-factum (https://gitlab.com/post-factum/pf-kernel/-/wikis/README), один к одному, то будет конечно толще ядро, но зато работоспособно на бОльших железках.
-
Если собирать по конфигу post-factum, один к одному, то будет конечно толще ядро, но зато работоспособно на бОльших железках.
так и сделал в 513-pf-lf5 пока никому нигде не помогло
-
Если собирать по конфигу post-factum, один к одному, то будет конечно толще ядро, но зато работоспособно на бОльших железках.
угу угу, я вот ядро конпеляю уже 10 лет, но вот совсем не могу сказать как этот драйвер точпада починить, и тем более не вижу чтобы модуль ядра был сломан.
Это я к тому, что "А ты как определил что модуль точпада сломан из-за конфига ядра? по каким признакам?"
-
я вот ядро конпеляю уже 10 лет
Поэтому на форуме есть вера в твои волшебные свойства + ностальгия.
-
ну так я свое мнение написал по поводу ядра, всплакните и думайте что делать.
-
думайте что делать.
зависит от версии ядра. Самое простое - откатываться на рабочую
По видеодровам от тебя мало инфы чтобы что-то думать
-
По видеодровам от тебя мало инфы чтобы что-то думать
достаточно факта.
1. точпад не работает
2. с видео проблемы
3. с загрузкой проблемы
Это ведь совершенно разные части не работают!!! Вывод: сделан.
-
ядро 5.13 - говно.
А у меня почему-то нормально...
-
выпуск: v5.15-pf2
* ядро обновлено до v5.15.4
* драйвер ksmbd обновлен с последними исправлениями
* реализация zstd обновлена в соответствии с последним состоянием
* удалена активная защита рабочего набора
* введена регенерация на основе DAMON
* набор патчей Multigenerational LRU был объединен
* обновлен набор патчей оптимизации ЦП
* Патчи Arch Linux были повторно синхронизированы
* сообщение `asus_wmi_sensors` было обновлено
Поскольку активная защита рабочего набора удалена,
`unevictable_ {file | anon} _kbytes_ {low, min}` sysctl-регуляторы больше не
действительный. Рассмотрите возможность использования защиты mgLRU, как показано здесь: [1].
https://gitlab.com/post-factum/pf-kernel/-/tags/v5.15-pf2
1. Изменения в uksmd (https://gitlab.com/post-factum/uksmd) (уже месяц как). Например, ksmd.service:
ConditionPathExists=/sys/kernel/pmadv/ksm, было /proc/self/ksm. А так же другие фиксы.
2. Удален le9-patch в пользу Multigenerational LRU (https://lwn.net/Articles/851184/)
3. Добавлен DAMON-based Proactive Reclamation (https://www.kernel.org/doc/html/latest/admin-guide/mm/damon/reclaim.html)
-
Multigenerational LRU
https://www.opennet.ru/opennews/art.shtml?num=54972
Обсуждение на рус. (https://www.linux.org.ru/forum/general/16321096)
https://justpaste.it/MGLRU
Мало что понял. Тут наверное надо как-то пробовать. Кто-нибудь пробовал? Есть смысл обновлять lf ядро?
Ну или надеяться, что к нам зайдет hakavlad и все разъяснит и даст пошаговые инструкции
Там же нашел https://github.com/oracle/memoptimizer/
memoptimizer-p-1.5.0_64-sf01.pfs (http://mirror.yandex.ru/puppyrus/puppyrus-a64/pfs-portable/memoptimizer-p-1.5.0_64-sf01.pfs)
Пока не пробовал
-
Что не так с le9, кстати?
Оно не идёт в апстрим, в отличие от mgLRU.
post-factum (https://www.linux.org.ru/forum/general/16321096?cid=16656888)
-
и ускорит обновление
Пока не надо, там post-factum пока в размышлениях, что оставить, mgLRU или le9. Вот как выйдет новый выпуск... Сейчас - v5.15-pf3.
Уже:
release: v5.15-pf4
* ядро обновлено до v5.15.7
* набор патчей mgLRU был возвращен
* защита отображения памяти была повторно введена
* последние исправления `ksmbd` были извлечены
* применены последние исправления `asus_wmi_sensors`
Этот тег не содержит примечаний к выпуску.
https://gitlab.com/post-factum/pf-kernel/-/tags/v5.15-pf4
Напомню изменения, которых нет в нашем дефолтном 5.13:
1. Изменения в uksmd (https://gitlab.com/post-factum/uksmd) (уже месяц как). Например, ksmd.service:
ConditionPathExists=/sys/kernel/pmadv/ksm, было /proc/self/ksm. А так же другие фиксы.
2. Удален le9-patch в пользу Multigenerational LRU (https://lwn.net/Articles/851184/)
3. Добавлен DAMON-based Proactive Reclamation (https://www.kernel.org/doc/html/latest/admin-guide/mm/damon/reclaim.html)
-
Не нашел где разместить новость.
Rui Ueyama, автор компоновщика LLVM lld и компилятора chibicc, представил первый стабильный релиз нового высокопроизводительного компоновщика Mold, заметно опережающего по скорости связывания объектных файлов компоновщики GNU gold и LLVM lld.
Например, при сборке Chrome 96 (размером кода 1.89 ГБ) на компоновку исполняемых файлов c debuginfo на 8-ядерном компьютере при использовании GNU gold тратится 53 секунды, LLVM lld - 11.7 секунд, а Mold всего 2.2 секунды (в 26 раз быстрее GNU gold). При компоновке Clang 13 (3.18 ГБ) в GNU gold требуется 64 секунды, в LLVM lld - 5.8 секунд, а в Mold - 2.9 секунды. При компоновке Firefox 89 (1.64 ГБ) в GNU gold необходимо 32.9 секунд, в LLVM lld - 6.8 секунд, а в Mold - 1.4 секунды.
Как пользоваться (https://github.com/rui314/mold/#how-to-use)
Если общее время компиляции какой-либо программы существенно(?) снизится, то будет неплохо, думаю.
mold 1.0.0-4 (https://archlinux.org/packages/community/x86_64/mold/)
AUR (https://aur.archlinux.org/packages/mold-git/)
-
Как пользоваться
На маленьких прогах выигрыш будет тоже маленьким
Из больших у нас компилится только ядро. Самостоятельно перепахать под новую фичу конфиги make я не возьмусь.
Надо ждать. Если вещь стоящая - все везде перейдут
-
компилить pf-aufs
Я все же, по прошествии двух недель, все более уверенно склоняюсь к полному pf и overlay.
А компилить, ну это не в домашних условиях. И я не думаю, что Pro, когда занимался ядрами, делал это на домашнем станционаре (могу ошибаться и там, возможно, стоит просто железный 'зверь' :)). Если только под свое железо, выкинув многое, чтобы сократить время сборки до возможного минимума, но не чувствую в этом потребности.
А чем будет хуже полный pf + aufs
Я компилил на i3. Меньше 2 часов. Да даже на твбоксе - там подольше
Ну или прикрутите к системе сборки, как пф
-
Выпуск 5.16 (https://www.opennet.ru/opennews/art.shtml?num=56478)
У автора pf убраны из списка (https://gitlab.com/post-factum/pf-kernel/-/wikis/README#ok-whats-there-in-your-patchset) патчи Damon и zstd, как вошедшие в официальное ядро. Это к вопросу:
А допилят вскоре все эти фишки для оптимизированной работы памяти и внесут в официальное ядро.
А так же, как и анонсировалось, удален le9 в пользу mgLRU. Кто не в курсе, это механизм работы с памятью от Google. Он уже давно используется на ChromeOS, где всегда было памяти в обрез, в пределах 1G, плюс–минус.
Так что спасибо hakavlad и его le9, он взбаламутил все это болото и его патч стали добавлять в оптимизированные ядра. В итоге, зашевелились и гугловцы со своим mgLRU и провели ряд оптимизаций кода с прицелом добавления в официальное ядро.
-
Выпуск 5.16
Уже компилю чтобы порешать с фат. На 515mgm опять проблема с загрузкой с фат. Видимо не хватает монолитных nls
-
релиз: v5.18-pf1 (https://gitlab.com/post-factum/pf-kernel/-/tags/v5.18-pf1)
* ядро обновлено до v5.18
* патчсет mglru обновлен до v11
* патчсет LRNG обновлен до версии 45
На что обратить внимание:
- продолжение усовершенствования mglru (аналог le9-patch), который обещан уже с 5.19, как часть стокового ядра
- дальнейшее развития инструментов работы с памятью, таких как DAMON и folios (входят в родное ядро), о которых упоминалось (https://forum.puppyrus.org/index.php?topic=23721.msg181963#msg181963) на форуме
Релиз ядра Linux 5.18 (https://www.opennet.ru/opennews/art.shtml?num=57235) (ссылка с opennet)
Еще, из не очень важных новостей, это переход uksmd (https://gitlab.com/post-factum/uksmd) на сборочную систему meson.
-
патчсет mglru обновлен до v11
патчсет LRNG обновлен до версии 45
Пробовали авторское ядро? Улучшения заметны?
переход uksmd на сборочную систему meson.
Думаю, конечному юзеру без разницы. Просто модная штука
-
Пробовали авторское ядро? Улучшения заметны?
Да, юзаю бинарное от автора.
По поводу улучшений относительно предыдущего, я руководствуюсь принципом, что развитие этих инструментов (упомянутых выше) 'кашу' не испортят. Поэтому добавляю 'не глядя'.
Могу только пояснить на своем опыте. Когда на моем компе, с ram 4G, я запускаю все чем пользуюсь - firefox с несколькими вкладками, mpv с видео, виртуалка с тяжелым MagOS.iso и десктопом KDE и запущенным в нем же браузером (тоже firefox) с воспроизведением роликов ютуба, :) то раньше комп просто 'замерзал'. Ситуация резко изменилась в лучшую сторону с появлением le9-path. Сейчас на замену ему пришел mglru и я всегда буду обновлять ядро, когда он будет патчиться - вещь полезная.
Про другие, упомянутые инструменты улучшения работы с памятью (DAMON и folios), сказать ничего не могу в добавок к тем тестам, что проводили сами разработчики.
p.s. Система prar2110 (64bit), используется zram.
-
я всегда буду обновлять ядро
Компилить с нашими фичами совсем часто трудоемко и только лишний гемор простым юзерам. Пока не планирую обновлять версию своих ядер. Если заметите улучшения - пишите...
-
Выпуск 5.16
Уже компилю чтобы порешать с фат. На 515mgm опять проблема с загрузкой с фат. Видимо не хватает монолитных nls
5.16 с моим initrd - kernel panic, не видит носитель, явно сделано под себя, чтобы моё не работало.
-
5.16 с моим initrd - kernel panic, не видит носитель
маленький монолитный 5.15.0-pf5-pt14, но с усеченным функционалом, который требуется редко.
Если потребовался - переходим на большое ядро :
5.16 - большое, для инитрд с юдев.
Без юдев - 5.15.0-pf5-pt14
-
инитрд с юдев.
А оно надо? И толсто, и тормозно. Пока модули ядра не подгрузились, невозможен поиск и загрузка модулей системы. Тебе не кажется, что это не наш метод?
-
А оно надо?
Чтобы каждый мог для себя это решить сам - сделал 2 ядра - большое и маленькое
-
Чтобы каждый мог для себя это решить сам
Для этого надо знать и понимать, а без этого скажут: "плохой дистрибутив". Заканчивай с этим многообразием, от него вред один. В добрые старые времена делали один дистрибутив, и он был популярен, а сейчас.... :(
5.15.0-pf5-pt14
На 5.15.0 не хочет "export DISPLAY" если процесс запущен до подъёма иксов, а это полностью блокирует запуск trayNet. Если это не "палки в колёса", то что?
-
Для этого надо знать и понимать
для тех, кто еще нет - в исо все настроено.
В добрые старые времена делали один дистрибутив, и он был популярен, а сейчас....
Какие критерии популярности?
На 5.15.0 не хочет "export DISPLAY"
А на других ядрах этой версии?
Если это не "палки в колёса", то что?
Не знаю где такое настраивается. Специально не выключал
-
А на других ядрах этой версии?
До 5.13.0 всё ok.
-
Ну так может дело в версии ядра...
-
Ну так может дело в версии ядра...
Возможно какую-то уязвимость закрыли, и это дало такой эффект.
-
Ну и вообще, по моим ощущениям, процесс Xorg -> Wayland последнее время везде ускорился
-
Вот и случилось то, о чем долго говорили. Мир линукса изменился. Теперь все те огромные объемы RAM, что наставили юзера в свои компы, можно делить на два. А выражение, "поставил 8G и браузер не вешает систему", уйдет в прошлое, и 4G оказывается за глаза хватает для среднестатистического пользователя (x86_64).
Релиз ядра Linux 6.1 (https://www.opennet.ru/opennews/art.shtml?num=58304)
В состав включён механизм MGLRU (Multi-Generational LRU), который заменил собой старую реализацию LRU (Least Recently Used) на основе двух очередей на многоступенчатую структуру, лучше определяющую какие страницы памяти по настоящему используются, а какие можно вытеснить в раздел подкачки.
-
Вроде в наших pf уже давно MGLRU ?
-
Вот именно, что в наших. А сколько юзеров не знали об этом патче, и годами почем зря ругали Linux... ) Теперь это дефолт, у всех.