The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэшированию запросов времени, opennews (??), 16-Янв-24, (0) [смотреть все]

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


71. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от Aliechemail (ok), 17-Янв-24, 08:11 
> Нельзя ли поконкретнее - про что это? File:line в студию? Сорц ядра у меня есть, я проверю.

Да пожалуйста. Ядро 6.1.61, например, файл: drivers/clocksource/arm_arch_timer.c. Отличный образчик обилия костылей, смотрите массив ool_workarounds, начиная со строчки № 437.

Но память меня подвела, и всё не настолько критично, как я это запомнил. В рантайме для таймера выбор хуков из device tree методом обхода всего массива в цикле, на данный момент, делается один раз - при инициализации. А потом просто каждый раз дёргается хук, при каждой попытке получения времени.

Но некоторые хуки такие красивые... Хук для Allwinner A64, например) Нет, конечно это говорит об качестве чипа, в первую очередь. Но ещё это и образчик того, как и без того не дешёвую операцию обращения к таймеру превратить в нечто совсем ужасающее. Хорошо хоть только для одного чипа.

И таких мест, где хуки распиханы по ядру, меняющие поведение и/или увеличивающие расходы на исполнение, много. Что есть следствие централизации разработки ядра.

Впрочем я нигде не писал, что идея кешировать обращение к таймеру - совсем не благодатная. Ибо всем понятно, что любые обращения к регистрам и портам - они весьма не бесплатные.

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

73. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –1 +/–
Сообщение от n00by (ok), 17-Янв-24, 09:05 
> смотрите массив ool_workarounds, начиная со строчки № 437.

А почему не с #ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND ?

или с


    wa = arch_timer_iterate_errata(type, match_fn, arg);
    if (!wa)
        return;
    __wa = __this_cpu_read(timer_unstable_counter_workaround);
    if (__wa && wa != __wa)
        pr_warn("Can't enable workaround for %s (clashes with %s\n)",
            wa->desc, __wa->desc);

> В рантайме для таймера выбор хуков из device tree методом
> обхода всего массива в цикле, на данный момент, делается один раз
> - при инициализации. А потом просто каждый раз дёргается хук, при
> каждой попытке получения времени.

А зачем вообще, хотя бы гипотетически, может понадобиться на каждый чих разбирать device tree?

В данном случае хук выглядит так:


#if IS_ENABLED(CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND)
...
#define erratum_handler(h)                        \
    ({                                \
        const struct arch_timer_erratum_workaround *__wa;    \
        __wa = __this_cpu_read(timer_unstable_counter_workaround); \
        (__wa && __wa->h) ? ({ isb(); __wa->h;}) : arch_timer_##h; \
    })
#else
#define has_erratum_handler(h)               false
#define erratum_handler(h)               (arch_timer_##h)
#endif

или я что-то недосмотрел?
Ответить | Правка | Наверх | Cообщить модератору

90. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от Aliechemail (ok), 17-Янв-24, 10:48 
> или я что-то недосмотрел?

Кажется да.

Если кратко: массив ool_workarounds (см. drivers/clocksource/arm_arch_timer.c) содержит записи со всеми доступными хуками. Каждая запись содержит в себе данные для сличения с devicetree и идентификаторы функций (содержаться в том же файле). Когда будет производится инициализация таймера, массив ool_workarounds будет прокручен в цикле, и каждая запись будет (по очереди) проверена на предмет соответствия данным из devicetree. И если соответствующая запись будет найдена, то в качестве хуков будут установлены те функции, которые в ней обозначены. Это если очень просто. Я сам не то, чтобы профессиональный разработчик ядра, мог напутать с терминологией.

Короче, ребятки приняли devicetree как источник информации о необходимости применения хуков, в т.ч. к системным вызовам. В случае с таймером всё ещё +/- нормально, так как это действо происходит только при инициализации таймера.

Но тут стоит посмотреть на код хуков. Вот хук, о котором я писал выше:


#define __sun50i_a64_read_reg(reg) ({                    \
    u64 _val;                            \
    int _retries = 150;                        \
                                    \
    do {                                \
        _val = read_sysreg(reg);                \
        _retries--;                        \
    } while (((_val + 1) & GENMASK(8, 0)) <= 1 && _retries);    \
                                    \
    WARN_ON_ONCE(!_retries);                    \
    _val;                                \
})

Вот с таким кодом только о производительности таймера и рассуждать. И об предсказуемости времени получения с него корректных результатов.

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

126. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –1 +/–
Сообщение от n00by (ok), 17-Янв-24, 15:30 
>[оверквотинг удален]
> Кажется да.
> Если кратко: массив ool_workarounds (см. drivers/clocksource/arm_arch_timer.c) содержит
> записи со всеми доступными хуками. Каждая запись содержит в себе данные
> для сличения с devicetree и идентификаторы функций (содержаться в том же
> файле). Когда будет производится инициализация таймера, массив ool_workarounds будет
> прокручен в цикле, и каждая запись будет (по очереди) проверена на
> предмет соответствия данным из devicetree. И если соответствующая запись будет найдена,
> то в качестве хуков будут установлены те функции, которые в ней
> обозначены. Это если очень просто. Я сам не то, чтобы профессиональный
> разработчик ядра, мог напутать с терминологией.

В эти дебри я вообще не вникал за ненадобностью. arch_timer_iterate_errata() вызывается 1 раз (код я привёл выше) и, судя по имени функции, результат применяется только для проблемного железа.

Для беспроблемного железа (определённая модель телефона, одноплатника и т.п.) можно вообще это всё убрать из ядра конфигом.

> Короче, ребятки приняли devicetree как источник информации о необходимости применения
> хуков, в т.ч. к системным вызовам. В случае с таймером всё
> ещё +/- нормально, так как это действо происходит только при инициализации
> таймера.

Насколько понимаю, это обычная практика. Точно так же на IA/AMD64 из ACPI, DMI и VID/PID определяется, надо ли применять qurks для другого оборудования.

>[оверквотинг удален]
>   _retries--;      \
>  } while (((_val + 1) & GENMASK(8, 0)) <= 1 &&
> _retries); \
>          \
>  WARN_ON_ONCE(!_retries);     \
>  _val;        \
> })
>
> Вот с таким кодом только о производительности таймера и рассуждать. И об
> предсказуемости времени получения с него корректных результатов.

Так если в каком-то частном случае с железом есть проблема, её приходится обходить, что бы хоть как-то работало.

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

119. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +1 +/–
Сообщение от Аноним (114), 17-Янв-24, 15:00 
> Отличный образчик обилия костылей, смотрите массив ool_workarounds,

Отличный образчик затыкания хардварных ERRATA софтом. И чего? Надо было сказать неудачникам с тем железом - "unsupported HW, факофф, грузиться не будем"? А точно система девелопаемая с таким подходом кому-то нужна?

У x86 тоже бывает зиллион приколов. Eg нестабильные частоты TSC или HPET, тот факт что TSC в ряде случаев не тикает если проц idle, и много чего еще.

> Но память меня подвела, и всё не настолько критично, как я это запомнил.
> В рантайме для таймера выбор хуков из device tree методом обхода всего массива в
> цикле, на данный момент, делается один раз - при инициализации.

А, ну то-есть признаете что все же попытались меня наесть. При инициализации - может хоть канкан танцевать, в разумных пределах. А вот в крейсерском режиме вон то было бы удивительно.

> А потом просто каждый раз дёргается хук, при каждой попытке получения времени.

Как по мне нормальная логика, ничего экстраординарного.

> Но некоторые хуки такие красивые... Хук для Allwinner A64, например) Нет, конечно
> это говорит об качестве чипа, в первую очередь. Но ещё это
> и образчик того, как и без того не дешёвую операцию обращения
> к таймеру превратить в нечто совсем ужасающее.

Было бы лучше совсем это зафейлить, или чего? Я вас не понимаю. Костыли обычно появляются когда хардвар "оставлял желать" и вообще - скажите спасибо что хотя-бы так а не фатальная ошибка и unsupported хардвар.

> Что есть следствие централизации разработки ядра.

Скорее наоборот - хуки позволяют куче тим разрабатывать под разные чипы, костыля косяки своего чипа как им там надо - не очень импактя соседей.

Кернел на арм нынче умеет мульти-бут как раз благодаря DeviceTree и при старте - определит на каком чипе (из набора поддерживаемых) оно взлетает, вкатит нужный хук, и в целом все довольно культурно - насколько кривизна энного чипа позволяла. А один кернель может подымать целый набор разных ARMов, разных вендоров, типа, почти как на x86.

Менее оптимально? Более сложный обвес? Ооок! Но это же не просто так. А потому что теперь можно вместо 20 кернелов под 20 железок сделать один - который цепляет их все - и runtime penalty в крейсерском режиме - таки умеренный. Поэтому оно того и стоило.

> Впрочем я нигде не писал, что идея кешировать обращение к таймеру -
> совсем не благодатная.

Ну как бы майнтайнеру блочной подсистемы, наверное, видно - нужны ли его downstream'ам/caller'ам вон те вещи или нет. Он правильный человек в правильном месте, у него есть BigPic в его области. Иначе он бы не был майнтайнером той подсистемы. И если он считает так, очевидно так оно и есть. И врядли кто-то квалифицирован лучше делать такое решение. Если это не так - возникает вопрос "почему он не был майнтайнером подсистемы?".

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

129. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от Умею пользоваться поисковикомemail (?), 17-Янв-24, 15:52 
> А, ну то-есть признаете что все же попытались меня наесть. При инициализации - может хоть канкан танцевать, в разумных пределах. А вот в крейсерском режиме вон то было бы удивительно.

Вас? Я таки признал, что ошибся, в части "дёргает devicetree при каждом вызове". Дело давно было, когда я туда заглядывал последний раз. Так что это я публично глупость спорол, предварительно не перепроверив. Зачем вы это выворачиваете осмысленной попыткой обманут конкретно вас?

> Кернел на арм нынче умеет мульти-бут как раз благодаря DeviceTree и при старте - определит на каком чипе (из набора поддерживаемых) оно взлетает, вкатит нужный хук, и в целом все довольно культурно - насколько кривизна энного чипа позволяла. А один кернель может подымать целый набор разных ARMов, разных вендоров, типа, почти как на x86.

Вы слишком очевидны, Капитан!

Но это, я разве не писал о том же? Вот выше же было:

> И таких мест, где хуки распиханы по ядру, меняющие поведение и/или увеличивающие расходы на исполнение, много. Что есть следствие централизации разработки ядра.

И да, я застал те "волшебные времена", когда какой-нибудь TI мог для своих OMAP'ов выкатить пару релизов ядер, а потом забить. И гуляйте. Но у всего есть всегда две стороны. Теперь "мы" выбрали одно ядро, которое должно запускаться везде. Чтобы больше не оказываться в ситуации, когда "прилип" к 2.6.18, а в mainline уже 3.x. Но... больше нет возможности иметь реально оптимизированные под железо ядра. Потому что такой глубины доработки не подразумевает общее ядро.

> Скорее наоборот - хуки позволяют куче тим разрабатывать под разные чипы, костыля косяки своего чипа как им там надо - не очень импактя соседей.
> Менее оптимально? Более сложный обвес? Ооок! Но это же не просто так. А потому что теперь можно вместо 20 кернелов под 20 железок сделать один - который цепляет их все - и runtime penalty в крейсерском режиме - таки умеренный. Поэтому оно того и стоило.

Так вот. Mainline на A64 крутился нормально некоторое время, пока не подвезли немножечко нового функционала для arm64. Который как-то косвенно повлиял на проявление этой ошибки. Стали ли откатывать что-то? Нет. Завезли несколько костылей, для конкретной errata. И плевать, насколько убогие эти костыли. А поправить это качественно, "не импактя соседей" не получается, по всей вероятности.

> Ну как бы майнтайнеру блочной подсистемы, наверное, видно - нужны ли его downstream'ам/caller'ам вон те вещи или нет. Он правильный человек в правильном месте, у него есть BigPic в его области. Иначе он бы не был майнтайнером той подсистемы. И если он считает так, очевидно так оно и есть. И врядли кто-то квалифицирован лучше делать такое решение. Если это не так - возникает вопрос "почему он не был майнтайнером подсистемы?".

Ну так я нигде не писал, что считаю его выбор не правильным. Настоятельно рекомендую перечитать эту фразу ещё пару раз:

> Впрочем я нигде не писал, что идея кешировать обращение к таймеру - совсем не благодатная.

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

133. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –1 +/–
Сообщение от n00by (ok), 17-Янв-24, 16:40 
>> А, ну то-есть признаете что все же попытались меня наесть. При инициализации - может хоть канкан танцевать, в разумных пределах. А вот в крейсерском режиме вон то было бы удивительно.
> Вас? Я таки признал, что ошибся, в части "дёргает devicetree при каждом
> вызове". Дело давно было, когда я туда заглядывал последний раз. Так
> что это я публично глупость спорол, предварительно не перепроверив. Зачем вы
> это выворачиваете осмысленной попыткой обманут конкретно вас?

Сам по себе факт, что тут признали ошибку открыто - большая редкость. Потому тот Аноним про это и написал. Плюс, у него такой стиль, что бы отличаться от других Анонимов, любящих говорить от имени "всех". Вот их "наесть" не получилось бы при всём желании - они всё равно ничего не поняли.

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

147. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –1 +/–
Сообщение от Аноним (-), 18-Янв-24, 00:14 
> Вас? Я таки признал, что ошибся, в части "дёргает devicetree при каждом вызове".

"В том числе и меня" - технически некорректным утверждением. Мне настолько жирный косяк показался подозрительным для майнлайна, обычно народ там понимает что делает и фирма ARM врядли позволила бы саботировать их чипы.

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

И это отлично. Не каждый сможет признать свою ошибку. Вы для меня стали на голову выше многих местных слабаков, неспособных на такое.

> Зачем вы это выворачиваете осмысленной попыткой обманут конкретно вас?

Обмануть ALL - хуже чем (попытаться) обмануть меня. Я привык смотреть на мир скептично, проверять input, нужное мне знание будет сэмплировано с нескольких точек и перепроверено, маневр скорее всего не удастся.

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

> Вы слишком очевидны, Капитан!

Бывает, блин.

> И да, я застал те "волшебные времена", когда какой-нибудь TI мог для
> своих OMAP'ов выкатить пару релизов ядер, а потом забить. И гуляйте.

Угумс, и такое бывало. Потом куча "machines" в arch/arm и проч. А ядро могло только 1 из цеплять. Потом ЭТО всем надоело и сделали DTB - "виртуальный плагнплей". Ядру так то пофиг какие драйверы грузить.

> нет возможности иметь реально оптимизированные под железо ядра. Потому что такой
> глубины доработки не подразумевает общее ядро.

Тем не менее...
1) Оверхед сам по себе обычно умеренный. Даже в том хуке, разовая инициализация и назначение энной функции само по себе довольно эффективно.
2) Ненужные фичи можно и не собирать как правило. Даже вон тот воркэраунд вроде ifdef'нут.
3) Premature optimization is a root of all evil (c). Это именно тот случай! Глядя на "machines" бардак с всем этим.

А так у меня есть например мои кернелы "для некоторых sunxi". А какую-нибудь тегру или квалком они не умеют. Потому что я с вот этими дело имею. Кернел окучивает некий выводох схожих железок, и хорош.

> этой ошибки. Стали ли откатывать что-то? Нет. Завезли несколько костылей, для
> конкретной errata. И плевать, насколько убогие эти костыли. А поправить это
> качественно, "не импактя соседей" не получается, по всей вероятности.

В случае ERRATA - p0 сделать так чтобы работало и не долбалось багом. И то что он не вылезал до этого - а это точно верно? Для всех случаев? А то бывает что - лезет, но редко. Чинить надо root cause а не слепо откатывать изменения подхайлайтившие проблему.

> Ну так я нигде не писал, что считаю его выбор не правильным.
> Настоятельно рекомендую перечитать эту фразу ещё пару раз:
>> Впрочем я нигде не писал, что идея кешировать обращение к таймеру - совсем не благодатная.

Ну вот и отлично, консенсус. А кернел так то не выбит в камне. Если кому-то зачем-то станет надо - еще что-то придумают. Они всегда так делают.

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

149. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +1 +/–
Сообщение от Aliechemail (ok), 18-Янв-24, 02:40 
> Угумс, и такое бывало. Потом куча "machines" в arch/arm и проч. А ядро могло только 1 из цеплять. Потом ЭТО всем надоело и сделали DTB - "виртуальный плагнплей". Ядру так то пофиг какие драйверы грузить.

И вот мы находимся в моменте, когда и dtb вроде бы внедрили, а в прод по-прежнему собираю несколько ядер. Потому что некоторые патчи, специфичные для rockchip, например, портят производительность/меняют поведения ядра, если с ними запускаться на sunxi, например. И появляется вопрос: а в полной ли мере сейчас оправдана идея одного ядра? Или всё-таки несколько вендоро-специфичных? // конечно это лучше рака, когда каждая плата требовала ядра

Тут скорее другой вопрос: а сможет ли комьюнити унести на своих плечах форк под платформу. Ну вот тот же sunxi. Такой глубины форк, чтобы даже на H6 pci-e заработал корректно. На мой взгляд - нет. Потому что вендоры сваливают железо, возможно ещё и SDK, а потом бодро умывают руки. А ведь ядро становится всё запутанней, релиз за релизом. И получается, что не

> В случае ERRATA - p0 сделать так чтобы работало и не долбалось багом.

а
"на более качественное решение нет ресурсов".

Так что одно ядро и dtb+хуки - это тупо надежда, что на купленных железках можно будет запустить свежее ядро. Но придётся смириться с обрезанным функционалом и прочей невозможностью адаптации. И вот мы не то, чтобы совсем ушли из той ситуации 2008-2009 годов, обозначенной выше.

> А так у меня есть например мои кернелы "для некоторых sunxi". А какую-нибудь тегру или квалком они не умеют. Потому что я с вот этими дело имею. Кернел окучивает некий выводох схожих железок, и хорош.

Ну я выше уже написал об аналогичной ситуации.

> В случае ERRATA - p0 сделать так чтобы работало и не долбалось багом. И то что он не вылезал до этого - а это точно верно? Для всех случаев? А то бывает что - лезет, но редко. Чинить надо root cause а не слепо откатывать изменения подхайлайтившие проблему.

Год+ до какого-то изменения, которое я упустил. Полёт нормальный был. Но однажды началось... Я тогда старался пользоваться ядром от дистрибутива, одним, везде... Ведь dtb, унификация и вот это всё. И вот ничто не предвещает беды... и после обновления системы на пяти платах плавающая проблема с улетающим в будущее таймером. Подарочек, блин.

Но это был полезный опыт. Так и в сортах хуков разбираться начинаешь, и к идее о необходимости собственной сборки ядер неотвратимо приходишь.

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

169. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –1 +/–
Сообщение от Аноним (-), 22-Янв-24, 03:26 
> И вот мы находимся в моменте, когда и dtb вроде бы внедрили,
> а в прод по-прежнему собираю несколько ядер. Потому что некоторые патчи,
> специфичные для rockchip, например, портят производительность/меняют поведения ядра,

Я использую майнлайн ядра. Если проблема мешает жить, я стараюсь чтобы ее устранили в майнлайн. И вроде рокчип норм поддерживается в майнлайн, сам вендор это делает. Что за патчи и зачем?

> если с ними запускаться на sunxi, например. И появляется вопрос: а
> в полной ли мере сейчас оправдана идея одного ядра?

Меня устраивает. Если кому надо дожимать последние проценты железки - он вероятно с выбором платформы облажался на старте. Это фейл другого порядка.

> Или всё-таки несколько вендоро-специфичных?
> // конечно это лучше рака, когда каждая плата требовала ядра

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

> Тут скорее другой вопрос: а сможет ли комьюнити унести на своих плечах
> форк под платформу. Ну вот тот же sunxi.

Вопрос другой: "а стоит ли оно того?" Premature optimization is a root of all evil (c).

> Такой глубины форк, чтобы даже на H6 pci-e заработал корректно. На мой взгляд - нет.

Поэтому я не буду закладываться на PCIe в H6. Или если ооочнадо, есть финт через гипервизор без патча майнлайна. Но реально это кривой pcie.

> потом бодро умывают руки. А ведь ядро становится всё запутанней, релиз за релизом.

Поэтому мое будущее майнлайн, с 0 патчей относительно него. Норм подход решить проблему в майнлайн и построить перфекционизм, имхо.

> "на более качественное решение нет ресурсов".

Разработка софта это сложный многофакторный процесс, а мир не идеален. С этим придется жить. Я люблю оптимизации и использование фич железа, но если цена за это слишком высока с другой стороны, для меня это соображение может перевесить. Мне не надо последние 5% перфоманса ЛЮБОЙ ценой. И pcie - тоже.

> Так что одно ядро и dtb+хуки - это тупо надежда, что на
> купленных железках можно будет запустить свежее ядро.

Это - унификация. И да, при этом придется немного слить оптимизации. Перфекционизм надо держать под контролем, неспособность это сделать воздается дурными проблемами.

> Но придётся смириться с обрезанным функционалом и прочей невозможностью адаптации.
> И вот мы не то, чтобы совсем ушли из той ситуации 2008-2009 годов, обозначенной выше.

Для меня DTB/NONDTB это очень принципиальная граница водораздела. С DTB я готов к будущему и могу переиграть ряд решений, унифицировать, ... без - упс.

Более того с DTB можно изменить лэйаут системы опосля, ну там датчик на i2c зацепив и прописав в dtb, и система увидит его - обычными дровами этого сенсора. "Почти plugnplay" для того что его никогда не умело.

> Ну я выше уже написал об аналогичной ситуации.

В этом смысле я бы старался во первых получить 0 размер патча vs майнлайн (кроме вон того), а во вторых - выбрал бы между перфомансом и затратами на майнтенанс исходя из того что мне актуальнее.

У меня довольно много типов девайсов развелось и я вполне могу выбрать и более простой майнтенанс, ибо никогда не беру платформы впритых, и ориентируюсь на майнлайн как есть.

> dtb, унификация и вот это всё. И вот ничто не предвещает беды... и после обновления
> системы на пяти платах плавающая проблема с улетающим в будущее таймером. Подарочек, блин.

Я гоняю некие квалификационные тесты на интересных мне железках в -rc обычно подарочки ловятся на подлете, а при нужде и бисектятся и причастные пинаются. Но в ряде случаев можно и дефернуть апдейты и проскипать версию ядра. Реально pressing поводов ядро апдейтить разве что вулны, при этом я могу откосплеить на минимуме майнтайнера и пропатчить вулн в том что там было - а более плотно заняться по мере возможностей.

> Но это был полезный опыт. Так и в сортах хуков разбираться начинаешь,
> и к идее о необходимости собственной сборки ядер неотвратимо приходишь.

Я конечно не юзаю на ARM дистровые ядра. Хотя-бы потому что мне с initrd зачастую лениво возиться. Это тоже некий tradeoff и имеет свои плюсы и минусы. Кроме того я порой весьма радикально переигрываю их конфиг, с оптимизацией и дефолтами на именно эмбед и то что там актуально. Скажем авторебут при панике по бырому, etc и ряд иных вещей.

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

152. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –1 +/–
Сообщение от n00by (ok), 18-Янв-24, 19:36 
Мне одно не вполне понятно, почему эту штука упорно называется хуком, а не колбеком, например. В моём понимании, хук, это когда функциональность отсутствует и её прикручивают чем-то типа синей изоленты. По запросу linux+kernel+hook первое попавшееся "At the time, it was a hot patching technology for Linux" https://www.programmersought.com/article/70331869018/ что я и ожидал увидеть. Через призму этой неточности остальной текст не вызвал удивления.
Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

154. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –1 +/–
Сообщение от n00by (ok), 18-Янв-24, 19:52 
> "At the time, it was a hot patching technology for
> Linux" https://www.programmersought.com/article/70331869018/ что я и ожидал увидеть.

ммм... это тоже вполне ожидаемо для первого попавшегося.


inline unsigned long disable_wp(void)
{
    unsigned long cr0;
 
    preempt_disable();
    barrier();
 
    cr0 = read_cr0();
    write_cr0(cr0 & ~X86_CR0_WP);
    return cr0;
}


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

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

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




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

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