Ядро без сжатия

>оперативки
Не влияет.

Скорость загрузки, на мой взгляд, более актуальна.

И она должна быть больше со сжатием. Даже атомы не могут быть настолько говном.

Выбери LZO, всё же, быстрее, чем остальное.

>И она должна быть больше со сжатием

Сомневаюсь. Это, наверное, актуально для HDD

Here are some original timings done on an Intel Pentium 133. Multiply by a constant factor for modern machines.

LZO1X decompression in C: ~16 MB/sec

Сколько же твоё ядро весит?

2,8 при сжатии в gzip

Как раз нет. С lzo ядро загружалось за ~2.67 секунд, с gzip - за 1.77

>С lzo ядро загружалось за ~2.67 секунд, с gzip - за 1.77
Вывод: без сжатия оно будет грузиться за >2.67 секунд. Потому, что gzip-распаковка — дольше, чем lzo. Выигрыш только за счёт меньшего размера файла.

> Скорость загрузки, на мой взгляд, более актуальна.
Ты упоротый? эти 0.12с не заметить.

PS bzImage(kernel + initramfs) 2.6MiB и 1.9с

>Вывод: без сжатия оно будет грузиться за >2.67 секунд

Вывод: x3al тупит. Без сжатия оно с харда дольше грузиться будет.

А теперь прочитай то, что я написал.

>Скорость загрузки, на мой взгляд, более актуальна.

Вот поэтому ядро сжатое gz/xz грузится значительно быстрее

Есть результаты конкретных замеров?

Да

Давай сюда

Зачем? Ты спросил - я ответил. Доказывать тебе что-либо - такую задачу я перед собой не ставил - не вижу смысла и профита.

>в выборе метода сжатия ядра версии 3.0 нет опции «none».

Она и 2.6 выпилена. Как раньше было — не помню, сжимал всегда gzip'ом, а сейчас захотел несжатое — в 37-ом ядре нету. Голый vmlinux не грузится грабом.

>Кто-то ещё считает мегабайты дискового пространства...?
мелочь

или оперативки?

а как сжатие повлияет? о_О

Скорость загрузки, на мой взгляд, более актуальна.

а теперь назови самую медленную часть компа и поймёшь где спряталось «/0»

>а теперь назови самую медленную часть компа

У меня это процессор, если судить по работе emerge и графикам io в коньках.

>С lzo ядро загружалось за ~2.67 секунд, с gzip - за 1.77

Это аптайм во время запуска init'а? Тогда распаковка тут ни при чём. Сначала ядро распакуется, потом начнёт грузиться и логгировать в dmesg сообщения со временем 0, а потом только начинается отсчёт времени для аптайма.

>Это аптайм во время запуска init'а?

Хз, о чём ты. Это временные метки загрузки ядра до запуска init

>У меня это процессор, если судить по работе emerge
ахахаха
да ты сам /0 ходячее

А в чём дело?

почитай, что такое емерж
потом очень хорошо подумай

>Хз, о чём ты. Это временные метки загрузки ядра до запуска init

Именно об этом. Тогда говорю же — они начинают считать время уже после распаковки и выполнения некоторого кода ядра. Они не отражают время распаковки.

А как посчитать время распаковки?

Так и будешь изъясняться в стиле астролога, или скажешь нормально?

> А в чём дело?
Иногда megabaks не объясняет почему прав. Самое тормозное место(если у тебя не ssd) это чтение/запись -> ты стреляешь себе в ногу.

>А как посчитать время распаковки?

Вероятно, можно написать патч на ядро, чтобы оно сохраняло где-нибудь в переменной в оперативной памяти значения, возвращаемые RDTSC до и после распаковки, а потом, когда ядро определит частоту процессора (что оно не всегда правильно делает, кстати), по разности значений определяло время распаковки и писало, например, через printk.

Если читать тему с комментами, можно сделать вывод, что у меня как раз SSD

В соседнем треде? SSD должен быть на /{usr/lib/var/etc/bin/sbin/ты понял}, остальное скорость загрузки не делает.

Какой процессор?

time tar xvfz arch.tgz ;)

Вот это откровения, прямо солнце из-за туч.

я бы попробовал none на ССД, но раз её нет, то хз

>Самое тормозное место(если у тебя не ssd)
На ssd оно же. RAM (жуткий тормоз по сравнению с процессором) на порядки быстрее ssd, даже если он в pci-express.

Тебе не кажется, что сравнивать их напрямик - несколько глупо?

Блин. Сделай бенчмарк, что ли. Сравни time cat uncompressed_image>/dev/null с time zcat gz_image >/dev/null и time xzcat xz_image >/dev/null. Только без кэша.

А где взять uncompressed_image?

/usr/src/linux/arch/x86/boot/vmlinux.bin как я понимаю. Да, на x86_64 путь не меняется.

> А где взять uncompressed_image?

Предварительно распаковать. К.О.

И да, его же и запаковывать. *zimage в странном формате и мне слишком лень думать, как его прочитать.

Как очистить кэш между тестами?

echo 3 > /proc/sys/vm/drop_caches

Ну, господа, наслаждайтеся:

time cat /usr/src/linux-3.0-gentoo/arch/x86/boot/vmlinux.bin > /dev/null

real    0m0.029s
user    0m0.000s
sys     0m0.003s

time zcat /usr/src/linux-3.0-gentoo/arch/x86/boot/vmlinux.tar.gz > /dev/null

real    0m0.041s
user    0m0.007s
sys     0m0.005s

time xzcat /usr/src/linux-3.0-gentoo/arch/x86/boot/vmlinux.tar.xz > /dev/null

real    0m0.060s
user    0m0.036s
sys     0m0.004s

root@acnote:/tmp/test# time { xzcat file.xz > /dev/null ; }

real    0m0.233s
user    0m0.089s
sys     0m0.014s
root@acnote:/tmp/test# xzcat file.xz > file
root@acnote:/tmp/test# echo 3 > /proc/sys/vm/drop_caches
root@acnote:/tmp/test# time { cat file > /dev/null ; }

real    0m0.080s
user    0m0.000s
sys     0m0.023s

Что и ожидалось. Однако в момент загрузки ядра GRUB'ом у тебя нет работающего в полную скорость диска и идеально работающего с файловой системой ядра, поэтому загрузка происходит достаточно долго - особенно заметно при загрузке ядра с USB, которая, бывает, занимает минуту, причем различается от одной машины к другой вне зависимости от мощности. Так что в данном случае каждый считываемый килобайт на счету

vmlinux.bin весит 3,5 Мб, .gz и .xz - 3,4 Мб. Правда, /boot/vmlinuz-3.0-gentoo весит почему-то 2,8 Мб

vmlinux.bin уже сжат.

rain@dbs86:~/buildfs/kernel/acnote/linux-3.0-rc4$ ls -lh vmlinux arch/x86/boot/vmlinux.bin 
-rwxr-x--- 1 rain rain 2,4M Июн 22 00:23 arch/x86/boot/vmlinux.bin
-rwxr-x--- 1 rain rain 7,6M Июн 22 00:23 vmlinux

Тьфу блин. Где взять несжатый образ?

dd if=/dev/urandom of=file bs=1M count=7

Тебе так критично, чтобы это образ реального ядра в данном случае?

/usr/src/linux-3.0-gentoo/vmlinux - не оно? Весит 15,6 Мб