The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Замена алгоритма сортировки в sysinit позволила ускорить загрузку FreeBSD, opennews (??), 21-Авг-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


30. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +3 +/
Сообщение от Аноним (30), 21-Авг-23, 11:09 
Вот куда надо было смотреть! А не пилить системд.
Ответить | Правка | Наверх | Cообщить модератору

48. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Аноним (52), 21-Авг-23, 11:59 
Ну вот да.
https://wiki.freebsd.org/BootTime
Ответить | Правка | Наверх | Cообщить модератору

146. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Аноним (-), 21-Авг-23, 23:52 
> Ну вот да.
> https://wiki.freebsd.org/BootTime

Судя по тому что там написано - там пашет аж 1 Персиваль и интересует его аж толко EC2 в амазоне. Если у вас не оно - вы пролетаете.

Еще дико доставили некоторые ремарки.
> The first time an EC2 instance boots, dhclient takes ~2200 ms for unknown reasons.

Или вот
> Reading the kernel from disk takes ~150 ms. This would be faster with a smaller
> and/or a compressed kernel, but tooling work would be needed for kernel updates.

Это что - бсда до сих пор не умеет в сжатые кернелы?

Ответить | Правка | Наверх | Cообщить модератору

187. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Аноним (127), 22-Авг-23, 20:16 
> Или вот
>> Reading the kernel from disk takes ~150 ms. This would be faster with a smaller
>> and/or a compressed kernel, but tooling work would be needed for kernel updates.
> Это что - бсда до сих пор не умеет в сжатые кернелы?

Это  просто ты до сих пор не умеешь в чтение.
https://man.freebsd.org/cgi/man.cgi?query=kgzip&sektion=8&ap...
> As    symbols    are lost, the usefulness of this utility for compressing kernels is limited to situations where loader(8) cannot be used; otherwise the preferred method of compressing a kernel is simply to gzip(1) it.
> July 19, 1999
>

Ответить | Правка | Наверх | Cообщить модератору

197. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Аноним (-), 23-Авг-23, 00:34 
>> Это что - бсда до сих пор не умеет в сжатые кернелы?
> Это  просто ты до сих пор не умеешь в чтение.
> https://man.freebsd.org/cgi/man.cgi?query=kgzip&sektion=8&ap...
>> As    symbols    are lost, the usefulness of this utility for compressing kernels is limited to situations where loader(8) cannot be used; otherwise the preferred method of compressing a kernel is simply to gzip(1) it.
>> July 19, 1999

Свежее, крутое и актуальное знание. Просто state of art. Последний писк 1999 года!
1) Я не понимаю почему "symbols" должны вообще теряться при таком. У линуха вот не теряются. В объеме достаточном для одупляемых трейсов. Если в конфиге ядра разрешить. Можно и совсем убрать для уменьшения размера, если это что-то типа роутера-мыльницы с опенврт.
2) Их внезапно можно хранить и в отдельном файле.
3) Если идет рубка за 2 миллисекунды, последнее во что мы хотели жать это gzip. Идея  в том чтобы чтение + анпак был быстрее чем чтение. И тут gzip абсолютно безблагодатен. С одной стороны он неважно по современным меркам жмет. Его мизерный словарь 32 килобайта ни о чем на чушке размером с кернел. С другой его скорость распаковки крайне печальна по современным меркам. Как простой пример zstd и радикально лучше жмет и декомпрессуется быстрее. А если носитель более шустрый, мы вообще LZ4 какой-нибудь хотели, где декомпрессия будет в гигах в секунду измеряться, а какое-то уменьшение чтения - будет.

В общем спасибо за характерное соотношение экспертизы и снобизма. А потом вы удивляетесь почему вас считают... тем чем счаитют.

Ответить | Правка | Наверх | Cообщить модератору

201. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от boomer (??), 23-Авг-23, 07:58 
>Последний писк 1999 года!

Потому что сжатие-распаковка образа ядра неэффективное решение, усложняющее сборку и запуск системы, но не дающее преимуществ.

Ответить | Правка | Наверх | Cообщить модератору

212. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Аноним (-), 23-Авг-23, 19:19 
> Потому что сжатие-распаковка образа ядра неэффективное решение, усложняющее сборку и запуск
> системы, но не дающее преимуществ.

А я в линухе этим пользуюсь. В том числе и потому что на ряде носителей прочитать с носителя и распаковать БЫСТРЫЙ алгоритм быстрее чем прочитать в 2..2.5 раза больше. А бонусом система меньше места занимает, а случаи бывают разные. Скажем вон там весь минимальный дебиан - с стометровым списком пакетов - живет в 256Mb NAND-флехе вообще. Ну вот есть у девайсв вот столько на борту. Система либо лезет в это либо упс - и это много кайфа с внешним рутом, вот уж нафиг.

А делается это 1 раз в жизни и на марафоне в ...цать лет наверное можно и позволить себе раз в жизни подраспереться для улучшения свойств оси.

На sd/emmc/raw nand это очень заметно время старта сокращает. На механических SSD тоже. На SSD - с быстрым алго сжатия. А сборка... эээ... с чисто практической точки зрения при сборке требуется лишь чтобы пакер выбраного алго был установлен в системе. А вот что это требует так это нормальных крутых системщиков способных это обыграть. То чего у фряшников кажется не осталось, раз технологию не смогли...

Ответить | Правка | Наверх | Cообщить модератору

220. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Аноним (127), 23-Авг-23, 22:46 
>> but tooling work would be needed for kernel updates.
> А делается это 1 раз в жизни и на марафоне в ...цать лет наверное можно и позволить себе раз в жизни подраспереться для улучшения свойств оси.

...
> А сборка... эээ... с чисто практической точки зрения при сборке требуется лишь чтобы пакер
> выбраного алго был установлен в системе.

ЯНХНП - это очередная демонстрация чтения альтернативными органами зрения, не совсем старческой деменции или просто такое завуалированое "этодругоепониматьнадо!"

Ответить | Правка | Наверх | Cообщить модератору

228. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Аноним (127), 24-Авг-23, 19:39 
> Свежее, крутое и актуальное знание. Просто state of art. Последний писк 1999 года!

Свежий, крутой и актуальный вспук. Просто state of the art.
Ты вопил "до сих пор нет сжатия" (сделав сей Ценный Вывод на основе "but tooling work would be needed for kernel updates" - видимо опять не глазами читал) - тебя ткнули в архив. Так что прекрати спрыгивать и юлить.

>> limited to situations where loader(8) cannot be used;
> 1) Я не понимаю почему "symbols" должны вообще теряться при таком. У
> линуха вот не теряются. В объеме достаточном для одупляемых трейсов. Если
> в конфиге ядра разрешить. Можно и совсем убрать для уменьшения размера,

Просто прекрати читать опой и фантазировать.

> 3) Если идет рубка за 2 миллисекунды, последнее во что мы хотели
> жать это gzip. Идея  в том чтобы чтение + анпак
> был быстрее чем чтение. И тут gzip абсолютно безблагодатен. С одной
> стороны он неважно по современным меркам жмет. Его мизерный словарь 32
> килобайта ни о чем на чушке размером с кернел. С другой его скорость распаковки крайне печальна по современным меркам. Как простой пример zstd и радикально лучше жмет и декомпрессуется быстрее. А если носитель более шустрый, мы вообще LZ4 какой-нибудь хотели, где декомпрессия будет в
> гигах в секунду измеряться, а какое-то уменьшение чтения - будет.

---
>> 1999
> zstd
> LZ4

Одним словом - "Ыксперд294".
> В общем спасибо за характерное соотношение экспертизы и снобизма. А потом вы удивляетесь почему вас считают... тем чем счаитют.

Какой ты однако самокритичный. А почему о себе - в третьем лице?

Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

61. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +1 +/
Сообщение от Аноним (61), 21-Авг-23, 13:11 
Лёня в сторону Micro$oft смотрел.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

182. "Замена алгоритма сортировки в sysinit позволила ускорить заг..."  +/
Сообщение от Анони (?), 22-Авг-23, 18:35 
> Лёня в сторону Micro$oft смотрел.

Поэтому нормального системного менеджмента в фряхе не дождетесь, лучше назло бабушке уши отморозить. Логика!

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру