Майкл Опденакер (Michael Opdenacker), занимающийся разработкой встраиваемых систем, рассказал (https://www.linux.com/news/event/open-source-summit-na/2017/...) о методах, которые позволяют сформировать минимальную сборку ядра и системного окружения, пригодную для применения на системах с несколькими мегабайтами оперативной памяти или используемую в качестве загрузчика других систем. В частности, показано (http://free-electrons.com/pub/conferences/2017/elc/opdenacke...), что несмотря на существенное разрастание кодовой базы ядра и забвение проекта по минимизации ядра (https://tiny.wiki.kernel.org/use_cases), вполне реально урезать современное ядро Linux до состояния, способного работать на системах с 2-6 Мб ОЗУ и требующего 2-4 Мб для размещения на постоянном носителе.Сокращение размера достигается не только отключением расширенной функциональности ядра ("make tinyconfig"), но и оптимизацией процесса сборки. Например,
сборка ядра Linux 4.10 при помощи gcc 6.2 для ARM позволяет на 0.4% сократить размер, по сравнению со сборкой в gcc 4.7. Включение режима "-Os" и оптимизаций на этапе связывания (LTO) в GCC ("gcc -Os -flto") даёт возможность сократить размер на 2.8%. Применение Clang 3.8.1 по сравнению с gcc 6.2 без LTO обеспечивает сокращение размера на 5%, а с LTO на 2.3%. Применение сборки с использованием набора инструкций Thumb ("-mthumb", смесь 16- и 32-разрядных инструкций для ARM) вместо ("-marm", 32-разрядные инструкции) позволяет сократить размер на 6.8%. Сжав ядро методом XZIP можно выиграть 6-10 Кб, а собрав ядро без поддержки ptrace можно сократить размер на ещё 14 Кб.
Проект LLVM Linux (http://llvm.linuxfoundation.org/), нацеленный на обеспечение (http://llvm.linuxfoundation.org/) сборки ядра при помощи Clang, заброшен в 2015 году, но разработчики из Linaro возродили работу и уже адаптировали (https://android-git.linaro.org/kernel/hikey-clang.git) патчи для ядра 4.9. В 2012 году для ядра были предложены (https://www.opennet.dev/opennews/art.shtml?num=34619) патчи, использующие LTO для отбрасывания неиспользуемого кода (например, для ARM патчи позволяли сократить размер на 6%), но они не были приняты в состав ядра так как Линус выступает против подобных оптимизаций, которые могут (https://www.opennet.dev/opennews/art.shtml?num=38293) привести (https://www.opennet.dev/opennews/art.shtml?num=40281) к непредсказуемому поведению.Аналогично показаны способы создания минимального системного окружения, которое требует для полноценной работы 8-16 Мб ОЗУ и, в зависимости от задач, занимает от нескольких сотен килобайт до 8-16 Мб дискового пространства. Окружение строится на основе системной библиотеки musl (https://www.musl-libc.org/faq.html) и универсальном наборе системных утилит toybox (http://landley.net/toybox/about.html), занимающим всего 84KB (BusyBox занимает 100Кб). Для сокращения размера файловой системы рекомендуется использовать initramfs, что позволит также обойтись без инициализации ФС и драйверов хранилища. Для встраиваемых систем с достаточным размером ОЗУ для сокращения размера рекомендовано использовать ФС со сжатием, такие как SquashFS, JFFS2 и ZRAM.
URL: https://www.linux.com/news/event/open-source-summit-na/2017/...
Новость: http://www.opennet.dev/opennews/art.shtml?num=46400
>всего 84KB (BusyBox занимает 100Кб)Целых 16кб разница!
Это целая банка памяти в спектруме!
А десять бабушек — уже рубль.
> 2017
> несколько мегабайт озу на устройстве
> у худшей Малинки целых 256
А у микроконтроллера, который навороченный, что его уже SoC называют, а не просто uC - STM32 (Cortex-M4/M7/H7) всё равно "только" 1-2 МБ на борту. А вот если ужать до 6 МБ, придётся подключить только небольшую SDRAM микросхемку и наслаждаться Ядром.
Линукс там всё равно не запустишь, потому что там нет MMU. Был MMU-less форк ядра, но он не обновлялся со временен 2.4.
Раньше нет. А в последнее время там разве ничего не поменялось? Ведь идут коммиты STM32. Вот уже и поддержку дисплеев опубликовали:
https://www.mail-archive.com/dri-devel@lists.freedeskto...С интересным комментарием: "Stm32f4 is a MCU platform which don't have MMU so the last patches developed by Benjamin Gaignard regarding "DRM: allow to use mmuless devices" are necessary."
arch/arm/Kconfig:config MMU
bool "MMU-based Paged Memory Management Support"
default y
help
Select if you want MMU-based virtualised addressing space
support by paged memory management. If unsure, say 'Y'.Т.е. можно отключить штатным конфигуратором.
Даже если это и используется только(?) в uClinux, то почему бы это не Линукс?
> Линукс там всё равно не запустишь,Однако на STM32F4 ядро все-таки запускают. См. arch/arm/mach-stm32 и пр.
>>и наслаждаться Ядром.Вижу ценителя тонкой иронии
Use boinc
Openwrt с не самым старым ядром (4.4) запускается на маршрутизаторах с 8Mb оперативной памяти. Найти что-то с меньшим объемом памяти сейчас довольно сложно.
> Найти что-то с меньшим объемом памяти сейчас довольно сложно.Почти любой MCU.
Для MCU есть свои ОС со своими плюсами и минусами. Да и задачи там совсем другие, многим из которых хватает и пары десятков килобайт ОЗУ.
Но при этом в этой отрасли существует большой спрос на вроде бы микроконтроллерные NuttX, VxWorks, QNX и т.п. из-за их POSIX/SUS-совместимости.
QNX, VxWorks - ни разу не микроконтроллерные ОС. Это абсолютно полноценные системы для полноценных процессоров.
А используют в индустрии из-за поддержки реалтайма и большого количества наработок.
А можно пример устройства с 8mb ram на котором запускается openwrt?
https://wiki.openwrt.org/toh/start
https://wiki.openwrt.org/toh/asus/wl600g
Там же 2 чипа по 8 (общий объем 16) или я чего не понял?
Да, там 16. И на офсайте информация, что нужно не менее 4 МБ пзу и 16МБ озу. А рекомендуется от 32 МБ озу.
На моей сетевой кормушке с openwrt:
Total Available 6720 kB / 28580 kB (23%)
Если отключить cron, dhcpd, lua и logd, то можно и 16mb ограничиться.
> На моей сетевой кормушке с openwrt:
> Total Available 6720 kB / 28580 kB (23%)
> Если отключить cron, dhcpd, lua и logd, то можно и 16mb ограничиться.Думаю, можно самому собрать под 16 МБ... Но если это чудо заставить работать шлюзом, то под нагрузкой железка ляжет.
На моей первой машине с Linux было 4Мб ОЗУ. 486DX2-66. Так там ещё и GUI стоял :)
Не тереби душу, как подумаешь, что в этих четырёх мегабайтах ещё и прикладное ПО крутилось, помимо ядра и гуёв...
Буржуй! Я начинал экспериментировать с "обезьянкой" еще на 386: приходя с работы, нажимал кнопку Включения и успевал поужинать - пока комп загрузится... :-)
Но трава была зеленее и звезды ярче! :-)
Да, всё было медленно, но это обуславливалось дисками, шинами и т.д. При этом какой-нибудь Lynx (или как он тогда назывался, когда на основе юникса был), записанный на тогдашнюю флэш память, запускался за секунды. такшта.Интересно, а есть ли гденить проект, где собрана информация по минимизации ядра на конкретных железках, или вообще, конфигуралка, запустил на компе, оно тебе посчитало, что там за модули используются и составила конфигурацию только с нужными модулями, есть такое? Возможно ли вообще такое?
>Возможно ли вообще такое?Уже очень и очень давно.
make localmodconfig, make localyesconfig.
О, не знал (не особо и лез в эти дела). Спасибо. И что, прям можно сканпелять и будет работать? А принтеры потом не отвалятся, или флэшки или пр.?
Вообще любой дистр запускается через initrd куда кладется модуль ядра - драйвер контроллера дисков, без него ядро не увидит диски и не подтянет остальные драйверы, соответственно остальные драйверы собраны модулями и подтягиваются по необходимости.А ядро где только все нужное..ну я хз, модуль для мыши логитек4теч это нужное?
А ну и соответственно в любой дистр входит тулза mkinitrd, которая как раз и определяет какие модули надо для загрузки и кладет их в initrd. И каждый дистр пилит свою версию тузлы у когото умнее у когото проще, но сути не меняет, обвязка для определения используемых модулей там же присутствует.
его демон дожен провисеть достаточно долго пока ты юзаешь полное ядроон просто собирает список всех модулей, которые загружались в ядро
т.е. если так ни разу за это время не подключишь устройство, модуль которого не загружается при старте системы, то да, его модуль не будет собираться
Спасибо, буду знать. Хотя, сомневаюсь, что это сильно уменьшит размер ядра в памяти, скорее место на диске чуть сэкономит.
> Спасибо, буду знать. Хотя, сомневаюсь, что это сильно уменьшит размер ядра в
> памяти, скорее место на диске чуть сэкономит.значительно ускорит сборку, когда я пробовал получилось раз в 5 быстрее
> Буржуй! Я начинал экспериментировать с "обезьянкой" еще на 386: приходя с работы,
> нажимал кнопку Включения и успевал поужинать - пока комп загрузится...Чо вы пя...тите, на 386SX-40 с 2 мегами он 1-1.5 мин. грузится.
> На моей первой машине с Linux было 4Мб ОЗУ. 486DX2-66. Так там ещё и GUI стоял :)на моей первой машине с линукс было тоже 4Мб ОЗУ. Это был Cyrix 6x86...
И там мало того что GUI стоял, там еще и в эмуляторе (Win4Lin) запускалась венда, которая на поверку работала в 2 раза быстрее оригинала.
>> На моей первой машине с Linux было 4Мб ОЗУ. 486DX2-66. Так там ещё и GUI стоял :)
> на моей первой машине с линукс было тоже 4Мб ОЗУ. Это был Cyrix 6x86...Это уже Пень, иди отседа, молодой ещё.:-P
на моем первом пентиуме ОЗУ - 32 мб и надо сказать - 95-я винда крутилась, офис, в пэйджмэйкере верстал газету, в кореле отрисовывал логотипы. Что-то сейчас так может?
Тебе расказать, что считалось в своё время на программируемых калькуляторах с 105 байт(не мега, не кило, просто байт) на код и 15-ю регистрами памяти?
Это у самой крутой модели. А у большинства - 98 и 14.
> Это у самой крутой модели. А у большинства - 98 и 14.МК-61 и МК-52 были на порядок распространённее, чем Б3-34 и МК-54 :)
У меня до сих пор МК-61 со справочником Дьяконова и старыми тетрадками с лекциями где-то на чердаке валяется... Выручал здорово, но стоил целую стипендию!
Эпоха... Есть что вспомнить... :-)
> У меня до сих пор МК-61 со справочником Дьяконова и старыми тетрадками
> с лекциями где-то на чердаке валяется... Выручал здорово, но стоил целую
> стипендию!
> Эпоха... Есть что вспомнить... :-)Аналогично. Дьяконов, Шелест... А тетрадка с программами даже в djvu переведена :)
http://airbase.ru/computers/pmk/progs/PMK.djvu
(Если это оно, а то на телефоне даже посмотреть сейчас djvu нечем :) )
>> У меня до сих пор МК-61 со справочником Дьяконова и старыми тетрадками
>> с лекциями где-то на чердаке валяется... Выручал здорово, но стоил целую
>> стипендию!
>> Эпоха... Есть что вспомнить... :-)
> Аналогично. Дьяконов, Шелест... А тетрадка с программами даже в djvu переведена :)
> http://airbase.ru/computers/pmk/progs/PMK.djvu
> (Если это оно, а то на телефоне даже посмотреть сейчас djvu нечем :) )А я могу: http://www.pixic.ru/i/I0G1W3F8i1l0e8n4.jpg
неужели ваш линукс так деградировал?
И эта ... там байтов - не было :) Ну если уж совсем занудничать :)
> И эта ... там байтов - не было :) Ну если уж
> совсем занудничать :)Байты были. Просто хранились не в параллельно адресуемой памяти, а в кольцевом буфере. Но всё равно, адресуемые. И даже, ЕМНИП, 8-битовые :) Хотя за последнее не ручаюсь, почти 30 лет прошло и внутреннюю архитектуру я уже почти забыл. Может, там память и ниблами адресовалась, тогда байт там был 4-х битный :)
>> Это у самой крутой модели. А у большинства - 98 и 14.
> МК-61 и МК-52 были на порядок распространённее, чем Б3-34 и МК-54 :)Это смотря в каком году оценивать.
Не забывайте ещё и про Б3-21.
> Это смотря в каком году оценивать.В абсолютных числах :) Б3-34 было выпущено мало. И они были экзотикой. А вот МК-61 наштамповали массово.
> Не забывайте ещё и про Б3-21.
Это была не просто экзотика, а ультраэкзотика :)
>> Это смотря в каком году оценивать.
> В абсолютных числах :) Б3-34 было выпущено мало. И они были экзотикой.
> А вот МК-61 наштамповали массово.
>> Не забывайте ещё и про Б3-21.
> Это была не просто экзотика, а ультраэкзотика :)(пожав плечами) Программируемый калькулятор на моём первом курсе _вообще_ был экзотикой. На группу было три штуки. Один Б3-34 и два МК-54, а 61-ых вообще не было.
> на моём первом курсе _вообще_ был экзотикой.
> На группу было три штуки. Один Б3-34 и два МК-54, а
> 61-ых вообще не было.Это в каком году? Я ПМК увлёкся в 1988 году. Тогда Б3-34 уже вообще давно не выпускался, а про МК-54 я только слышал. Зато МК-61 был дефицитом, но доступным. Я с появления денег до покупки ждал пару месяцев. Пару лет спустя, в 1990 брал МК-52 вообще свободно. Один МК-61 и один МК-52 ещё были у друзей. И потом штуки три МК-61 у одногруппников. МК-54 я так никогда живой и не видел, а Б3-34 только в середине 1990-х у коллекционера :)
>> на моём первом курсе _вообще_ был экзотикой.
>> На группу было три штуки. Один Б3-34 и два МК-54, а
>> 61-ых вообще не было.
> Это в каком году?1984. Вы так спрашиваете, будто до 1988 года и других годов-то не было :-)
Ну и чуть чуть арифметики. Для времен win95 рабочее разрешение экрана было 640x480 и 256 цветов, то есть один байт на точку. Что требует 300kb памяти. При наличии одного буфера еще столько же. То есть требования к видеопамяти меньше 1mb. Также в 1mb можно уложиться при разрешении 800x600 и теми же 256 цветов. А вот сейчас основным рабочим рарешением является 1920x1080 и 32 бита на цвет. Что требует почти 8 метров, а с буфером всех 16. То есть раньше на изображение уходила одна 32-я памяти, а сейчас с той же памятью это будет половина. И если тебе захочется уложиться в те же требования по памяти, то придется вернуться и к тому же разрешению экрана. Точно этого хочется?Всё вышесказанное никак не отменяет того, что большая часть современного ПО значительно менее эффективно работает с памятью, чем ПО 20-летней давности, решая при этом _почти_ те же задачи.
> Ну и чуть чуть арифметики. Для времен win95 рабочее разрешение экрана было
> 640x480 и 256 цветов, то есть один байт на точку.Это, простите, где такие ужасы были? Лично застал появление вин95, причём не в мск. Везде, где это видел - было от 800х600 HiColor, если у меня совсем память не отвалилась.
>Это, простите, где такие ужасы были?В Windows 3.1. Фотку моих седых мудей сам найдешь.
Это зависит от того, где видели. Если у людей, работавших с графикой, то там конечно железо позволяло больше. Но среди офисных машинок тех времен нормой была S3Trio64 с одним метром памяти и там 800x600 hicolor не поставишь, нужно хотя бы два метра.
Ради интереса можно поискать на торрентах какие-нибудь книги по вебдизайну конца 90-х и посмотреть под какое разрешение экрана там советовали оптимизировать сайты.
> S3Trio64 с одним метром памяти и там 800x600 hicolor не поставишьУ меня такая была. Ставил.
> нормой была S3Trio64 с одним метром памятиЭта карта появилась на свет только в 1995 году, а в России стала популярна только с рубежа 1996/1997 годов и в продвинутых модификациях активно использовалась в офисных машинах до начала 2000-х.
> Но среди офисных машинок тех времен нормой была S3Trio64 с одним метром памяти и там 800x600 hicolor не поставишь, нужно хотя бы два метра.С 1МБ видеокартой S3Trio64 получалось 65536 цветов 800x600 пикселей на 14" мониторе. Прекрасно шёл Quake под Windows 9x/NT4.
> Везде, где это видел - было от 800х600 HiColor,800 на 600 ещё надо было заработать. Как и сопроцессор, кстати.
>Также в 1mb можно уложиться при разрешении 800x600 и теми же 256 цветов.Я пользовался разрешением 1024x768 при 256 цветах - в мегабайт вмещалось. Работалось достаточно комфортно. Сейчас только глубина цвета увеличилась до 32 бит и экран расползся вширь, что комфорта работе не добавило ничуть. Видео на ютубе, конечно, при 256 цветах не посмотришь, но если бы браузер при развёртывании видео на полный экран переключался бы в режим 800x600 при 16 бит, то этого было бы вполне достаточно для просмотра видео - это разрешение тоже умещается в 1 мегабайт.
> при 16 бит, то этого было бы вполне достаточно МНЕ для просмотра
> видео - это разрешение тоже умещается в 1 мегабайт.Исправил, не благодари.
Busybox - это же как архиватор, что засунешь в него, то он и будет уметь. И места жрать соответственно.
> Busybox - это же как архиватор, что засунешь в него, то он
> и будет уметь. И места жрать соответственно.Пермиссивным борцам с GPL это все равно.
Актуально для LEDE и желающих оставить поддержку роутеров с 4Mb RAM!
Я не очень понимаю. Они пытаются приспособить ядро+userspace (минимальный) к 8-16 MB RAM, когда на 8ми работали 95е форточки. Где подвох?
Линукс времен win95 тоже требовал мало памяти. Но ни его, ни форточки на современном железе уже не запустишь. Ну и железки, где стоит такое количество памяти, совсем не десктопы и гуй там не нужен.
Есть ещё ESP8266 и аналоги! Очень распространённые семки =) Но взять какой-нить нормальный одноплатник всё равно проще и не шибко дороже.
Ну почему?
>когда на 8ми работали 95е форточки. Где подвох?Запусти 10-ку на таком объёме памяти, потом приходи всех поливать ...
Ну а не запустишь - утопись в нём сам! :))))
судя по оригинальной презентации, время от времени кто-то пытается что-то начать делать, но потом забрасывает. потому что добавить 16мб памяти дешевле, чем тратить время разработчиков на оптимизации
Проблема современного ПО даже не в том, что оно жрет память как свинья, а в том, что не понятно зачем ему столько памяти. Если с видео памятью все понятно разрешение X глубина цвета+ N буферов, то с оперативкой мрак полный.
Ну как же. Жабаскриптом транслировать видео про котиков в 4k.
Кто бы написал статью - минимальный линукс для нормального десктопа по шагам с легким GUI. Начиная с минимального размера, чтобы ничего лишнего не было, и с объяснениями, что вообще тут у нас есть и зачем. И чтобы всё летало :). Помню как-о экспериментировал, ставил арч и в него оперу. Она ставилась махом с минимумом файлов. А ставишь какой-нибудь файрфокс, там 100500 файлов. А по функциям вроде никакой разницы. А файлы системы вообще чтобы в память грузились.
LFS?
> Кто бы написал статью - минимальный линукс для нормального десктопа по шагам
> с легким GUI.BLFS не возьмёте?
Почитайте более интересную статистику https://lkml.org/lkml/2017/4/4/710
