Японская компания Lineo (http://www.lineo.co.jp/eng/), занимающаяся производством встраиваемых устройств, представит (http://www.linuxdevices.com/news/NS5185504436.html) на выставке Embedded Technology 2008 новую технологию быстрой загрузки встраиваемых дистрибутивов Linux. Технология получила название Warp 2 (http://www.lineo.co.jp/eng/news-events/press-release/2008110...) и позволяет сократить время загрузки полностью готового к работе графического окружения более чем в 10 раз.
Например, тестовое окружение на базе X.Org, twm и трех xterm процессов загружается на плате Armadillo-500 (http://www.atmark-techno.com/en/products/armadillo/a500) (400MHz ARM11 CPU) с NAND Flash стандартным методом за 31.11 сек., а при использовании Warp 2 - за 2.97 сек.
Суть метода в предварительной записи на Flash готового образа состояния памяти после загрузки, аналогичного создаваемому при организации засыпания устройств со сбросом памяти на диск (hibernate или suspend to disk). При использо...URL: http://www.linuxdevices.com/news/NS5185504436.html
Новость: http://www.opennet.me/opennews/art.shtml?num=18808
Топик провокационный. Сабж относится только к встраиваемым устройствам, а не к десктопам!
> аналогичного создаваемому при организации засыпания устройств
> со сбросом памяти на диск (hibernate или suspend to disk).И вся фишка.
А кто/что мешает применить к Десктопам? Вот только, чтобы получить нормальный образ, - придется "хибернет" солидно допилить под конкретное железо. Думаю, что скоро начнут впихивать в загрузчики "быстрый старт", или что-то в этом роде. Дел то, после успешной инстляции сохранить образ с начальными настройками для дальнейшего использования, а остальное уже активировать после старта образа.
> Вот только, чтобы получить нормальный образ, - придется "хибернет" солидно допилить под конкретное железосогласен, я на asus eee pc решил настроить suspend to disk,
так получилось что время на считывание образа памяти размером в гиг почти равно времени обычного старта системы
(над самой системой я предварительно потрудился, выкинув всё что не нужно при каждой загрузке, например nfs, который используется только дома)
Это какие-такие eeePC идут с гигом озу на борту o_O?
EeePC 900
Разве не все?
Ну да, у них ведь всего 32 мб.
Образ памяти, наверное, нужно брать только используемый, а не весь наявный RAM. Но как это сделать стандартным "хибернетом", я не знаю. Сейчас сижу на SuSE KDE4, памяти занято 351Мб. Это уже всякой дряни полно загружено, один firefox чего только стоит. Думаю тема стоит размышления и работы. Нужно решить, как скинуть образ только используемой памяти.
>работы. Нужно решить, как скинуть образ только используемой памяти.ИМХО - забить до старта нулями оперативу.А потом сливать с компрессией.Нули сожмутся в ничто.Тупо, топорно и скорость при выборе правильного алгоритма сжатия будет ограничена скоростью записи на диск, а не процом как правило... :-).
А какие проблемы применить это к декстопам то?Хибернация - боян.
>Топик провокационный. Сабж относится только к встраиваемым устройствам, а не к десктопам!Хм... А вот интересно, а выгружается она так же быстро?
А то толку-то... Всего-то поменяли местами время старта и время финиша...
Да и в embedded области время старта дело десятое... Станку который должен без т/о проработать годы пофигу сколько времени будет стартовать СПО. Как сказал один заказчик - ХОТЬ ТРИ ЧАСА - НО ЧТОБ ПОТОМ ПЯТЬ ЛЕТ К НЕМУ ВООБЩЕ НЕ ПОДХОДИЛИ.
Так что актуально только на игрушках/смартах и т.п. А это тема другого разговора и на другую тему (тему о целесообразности Linux в данном сегменте).
как раз для embedded не десятое дело время загрузки если железка будет использоваться в медицине.
>Хм... А вот интересно, а выгружается она так же быстро?А в чем проблемы - слить буфер на диск (или "диск") и выключаемся.Все симметрично.
Не быстро - это время незапланированного рестарта.Если система внепланово срублена где-то в середине (слет питания, паника ядра, аппаратный reset, ... ) а образ на диск не был слит - вот тут придется сделать честную и медленную обычную перезагрузку + проверку ФС.Состояние образа памяти на диске при этом более не соответствует состоянию ФС.Замороженная в нем система не ожидает увидеть ФС в измененном состоянии так что попытка раскатать образ в RAM после некорректного рестарта наверное приведет к разрушению данных в файловой системе.>А то толку-то... Всего-то поменяли местами время старта и время финиша...
Никто ничего не менял.При *запланированом* шатдауне образ оперативы сливается на диск точно так же как и заливался и дальше отключение питания.
>Да и в embedded области время старта дело десятое...
Неправда ваша, в embedded это порой очень критично.Потеря управления на 2 секунды и на минуту - разные вещи.Потеря контроля над процессом на 2 секунды допустима гораздо чаще чем потеря контроля над процессом на целую минуту.
>ПЯТЬ ЛЕТ К НЕМУ ВООБЩЕ НЕ ПОДХОДИЛИ.
Заказчики бывают разные.Прикиньте?А embedded это не только ваш станок и ваш заказчик.
>Так что актуально только на игрушках/смартах и т.п.
Опять же неправда ваша.Даже взять банальный роутер который на embedded то с трудом тянет: если он придет в себя за 2 секунды - никто и не заметит вообще что он сребутился.А если он будет 2 минуты тупить - народ не только заметит ребут но и все TCP соединения вообще оборвутся.Ну а бортовой компьютер например - извините, но сосать без навигации 2 минуты на быстро движущемся объекте куда хуже чем 2 секунды.
овации
Даешь загрузку системы с 4.х кедами и компизом за 1.5 сек. на десктопах!!!
>Даешь загрузку системы с 4.х кедами и компизом за 1.5 сек. на
>десктопах!!!не, монитор будет дольше 1.5с. мигать при переключении граф. режимов :))) сначала от экрана биоса до экрана груба, потом от груба до сплэшскрина загрузки, потом от сплэшскрина до иксов :))
>не, монитор будет дольше 1.5с. мигать при переключении граф. режимов :))) сначала от
>экрана биоса до экрана груба, потом от груба до сплэшскрина загрузки, потом от сплэшскрина до иксов :))Это прошлый век. Какой нафиг монитор? моментально режимы должен менять. Какой нафиг БИОС? Еще скажи, что в современных компьютерах должна быть проверка памяти при запуске, как на моем старье. Компу на инициализацию и посыла загрузки загрузчику ОС должно хватать секунды. ОС должна грузиться за 4 секунды до экрана приветствия.
Работал же раньше ДОС, да еще на древнем железе.
>ОС должна грузиться за 4 секунды до экрана приветствия.Поздно, линукс уже захакали до "за пять секунд в сессию XFCE на EeePC с успокоившимися процессором и диском, но без поднятого WiFi": http://lwn.net/Articles/299483/
> Для сокращения места для хранения образа возможно использование сжатия, что немного замедляет загрузкуСжатие надо было правильное юзать. QuickLZ или LZO пожалуй еще и ускорят и запись и чтение образа.Как минимум на традиционный хард =)
Это секлаб? Здесь текст новости читать не принято?>на плате Armadillo-500 (400MHz ARM11 CPU) с NAND Flash
О каком "традиционном харде" может идти речь в подобных системах?
А на ARM-е сжатие не будет быстрее, чем чтение из flash. Запись - может быть, если флешка долгозаписывающая.
>Это секлаб? Здесь текст новости читать не принято?Это не секлаб но вот красноглазых выступающих тут что-то не меньше стало.Пионеры и прочие школьники видимо добрались до компов :(
>>на плате Armadillo-500 (400MHz ARM11 CPU) с NAND Flash
>О каком "традиционном харде" может идти речь в подобных системах?Во первых, я нигде не утверждал что это относится именно к данной железке.Для тех кто в танке намекаю: тут был еще и разговор про десктопы заодно.
Во вторых - "вы этого хотели?Нате!" - есть такаие штуки, NAS называются.Очень часто делаются на ARMах от Marvell + Linux.Какой, спрашиваете там хард?Обычный, как правило 1 или несколько SATA дисков.И архитектурно данные девайсы не сильно то и далеко ушли от этой штуки если что.Довольны? =)>А на ARM-е сжатие не будет быстрее, чем чтение из flash.
Во первых никакого "сжатия при чтении из флеш" не производится - производится декомпрессия.И чтоб вы знали нынче есть алгоритмы (на основе LZ), скорость декомпрессии которых не шибко далека от скорости простого memcpy() и измеряется многими мегабайтами в секунду даже на небыстрых процах (LZ-based крайне просты в декомпрессии и все как правило сводится к копированию данных, при том исходных данных читать надо в разы меньше чем без сжатия).Чтение из NAND обычно здорово тормознее чем работа с каким-нить DDR.Даже NOR тормознее популярной нынче DDR-оперативки, а уж NAND и подавно сливает с треском во многие разы.Так что тут еще вопрос кто кого.Если по уму все делать - на чтении из NAND'а сэкономится не факт что меньше чем проиграется на декомпрессии.
> Запись - может быть, если флешка долгозаписывающая.
Я бы дал 50\50, у LZ-based сжатие, даже халтурненькое, все-таки посложнее декомпрессии.Это все бенчить надо.В конкретной системе с ее особенностями.
А слабО записать ядро сразу в ПЗУ, чтобы оно непосредственно оттуда и исполнялось, не загружаясь в ОЗУ, как это было на ZX-Spectrum, и как это делается сейчас на микроконтроллерах?
>А слабО записать ядро сразу в ПЗУ, чтобы оно непосредственно оттуда и
>исполнялось, не загружаясь в ОЗУ, как это было на ZX-Spectrum, и
>как это делается сейчас на микроконтроллерах?Угу... Хотел-бы я бы такую железку. Проц на арме, не греется, много энергии не жрет, занимает мало места (там вроде даже радиатор то не нужен), пзу с ядром и образом, ОЗУ на 128 метров, вайфай, тачскрин на 8", ssd на 64 ГБ и еще что-нибудь... Мечта идиота) Можно как минимум смотреть фильмы, слушать музыку, работать частично (можно усб мини клаву подрубить), в инете посидеть. А если такой девайс пойдет в массы - то самое дорогое в нем будет - ssd и тачскрин.
Так продавал же сименс - никто не покупал
фильмы это едва потянет
а Intel Atom тоже почти не греется
ну а в чем проблема поставить 2 или больше? тогда мультипоточность будет (как раз для мультимедии)
>А слабО записать ядро сразу в ПЗУ, чтобы оно непосредственно оттуда и
>исполнялось, не загружаясь в ОЗУ, как это было на ZX-Spectrum, и
>как это делается сейчас на микроконтроллерах?Действительно, а кто-то знает, как в стандартную материнку впихнуть ядро? Хотел бы попробовать. На XT, AT когда-то была возможность установить ПЗУ с Бейсиком и стартовать с него, интересно, эта возможность осталась в современных материнках с их биосами?
http://www.coreboot.org/
coreboot (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers.
Несмотря на название, в этом LinuxBIOS линукса как такового нет, его функции аналогичны обычным проприетарным бивисам.
Согласен, но вопрос был -"...как в стандартную материнку впихнуть ядро?..."...Целью проекта Coreboot является замена проприетарных и закрытых BIOS, используемых большинством персональных компьютеров, на легковесный BIOS, предназначенный исключительно для загрузки и запуска современных 32 и 64 разрядных операционных систем.
Типичная задача coreboot — загружать ядро Linux, но, кроме этого, coreboot может загружать и запускать исполняемые файлы в формате ELF...
http://ru.wikipedia.org/wiki/Coreboot
Вроде само ядро в биос и не входит. Его придется куда-то устанавливать, если я правильно понял этот проект.
Верно, в исходный код не входит, поэтому либо надо взять готовый бинарный код (или купить) или изучить на сайте руководства по сборке.
http://www.coreboot.org/Payloads
- coreboot in itself is "only" minimal code for initializing a mainboard with peripherals. After the initialization, it jumps to a payload...
...Coreboot can use a Linux kernel as payload directly. That is, the kernel is included in the ROM chip where coreboot resides.
Alternatively, you can also boot a Linux kernel from your hard drive using either the FILO or GRUB2 payloads, of course.
Всетаки видимо есть:# Fast boot times (3 seconds to Linux console)
Спасибо всем за совет, попробую изучить этот проект.
Если бы ядро было зашито в ПЗУ и исполнялось бы непосредственно оттуда, то оно должно загружаться не за целых три секунды, а за миллисекунды. Вспомните ZX-Spectrum.
>Если бы ядро было зашито в ПЗУ и исполнялось бы непосредственно оттуда,
>то оно должно загружаться не за целых три секунды, а за
>миллисекунды. Вспомните ZX-Spectrum.Это с каких пор ROM быстрее RAM того же периода стал? Спектрумы, атари и компания бутались отнюдь не за миллисекунды.
ROM не быстрее RAM. Просто не надо тратить время на распаковку и копирование из ROM в RAM.
Спектрум "грузился" почти мгновенно, причем он мог бы делать это еще мгновеннее, если бы не обнулял при этом оперативку.
Радио-86 РК и Орион-128 "грузились" мгновенно.
Атари - не знаю, не видел.
>ROM не быстрее RAM. Просто не надо тратить время на распаковку и
>копирование из ROM в RAM.
>Спектрум "грузился" почти мгновенно, причем он мог бы делать это еще мгновеннее,
>если бы не обнулял при этом оперативку.
>Радио-86 РК и Орион-128 "грузились" мгновенно.
>Атари - не знаю, не видел.Да они не грузились. В ПЗУ находился монитор, который и выполнял команды прямо в ПЗУ. Все, что нужно было, это произвести инициализацию "единственного" известного минимума оборудования и вывести строку приглашения для ввода приметивных комманд. Да и что там было инициализировать??? Запустить цикл на сканирование клавиатуры и в видео-память загнать текст с приглашением.
Да, они не грузились. Именно поэтому я взял это слово в кавычки.
>Спасибо всем за совет, попробую изучить этот проект.Оно далеко не на всём ездит, готовьте хорошие отношения с поставщиками железа или крепкий напильник. У нас один из поддерживаемых Foxconn в офисе есть, но от промышленного использования на данный момент отказались -- не настолько критично...
Есть загрузка, а есть выход из сна. Две разные вещи. Зачем называть выход из сна загрузкой ? Где инновация ?
А сколько геммороя обновить такой образ после, обновления пакетов из репозитория ?
>Зачем называть выход из сна загрузкой ? Где инновация ?Инновация в том, что вместо загрузки делается процедура, аналогичная выходу из сна. Даже если перед этим компьютер был выключен, а не "усыплен".
Посмотри, сколько времени грузится, например, типичный домашний ADSL-маршрутизатор. Некоторые - более минуты! (от момента включения до запуска pppd). Там подобная техника бы явно не помешала.
Похожая функциональность есть в патче tuxonice:config TOI_KEEP_IMAGE
This option allows you to keep and image and reuse it.
...Правда доводить до юзабельного состояния для домашней машины я бы пока не взялся