The OpenNET Project / Index page

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

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


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

Оглавление

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

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


10. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –1 +/–
Сообщение от Aliechemail (ok), 17-Янв-24, 00:15 
Шаг 1. Для унификации всего подряд (где-то в районе перехода на 3ю и 4ю версии ядра, чтобы Гуглу проще было с зоопарком ядер на Андройд) делаем возможность подменять системные вызовы ядра на железо-специфичные хуки. Достигается это через разбор кучи условий, в т.ч. через просмотр device tree прямо в рантайме. То есть через лишние накладные расходы к банальному вызову time().
Шаг 2. Думаем, как бы нам кешировать результат системного вызова time(). Ведь системные вызовы такие не быстрые, да.
Ответить | Правка | Наверх | Cообщить модератору

29. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +4 +/–
Сообщение от Аноним (-), 17-Янв-24, 01:20 
> Шаг 1. Для унификации всего подряд (где-то в районе перехода на 3ю и 4ю версии ядра,
> чтобы Гуглу проще было с зоопарком ядер на Андройд) делаем возможность подменять
> системные вызовы ядра на железо-специфичные хуки. Достигается это через разбор кучи
> условий, в т.ч. через просмотр device tree прямо в рантайме.

Нельзя ли поконкретнее - про что это? File:line в студию? Сорц ядра у меня есть, я проверю.

> То есть через лишние накладные расходы к банальному вызову time().

1) Ядро != юзермод и у него свои внутренности, которыми оно может пользоваться и без всяких сисколлов. И если еще и посмотреть сабжевый код - оно там внутренние фичи ядра и дергало.
2) Смотрение на часы никогда не было какой-то особо простой и дешевой операцией...

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

34. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –4 +/–
Сообщение от Аноньимъ (ok), 17-Янв-24, 01:27 
> 2) Смотрение на часы никогда не было какой-то особо простой и дешевой операцией...

Почему?

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

39. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +5 +/–
Сообщение от Аноним (39), 17-Янв-24, 01:47 
Потому что:
а) часы - это устройство ввода-вывода, а значит работа с ними - уже недешевое по меркам процессора удовольствие (впрочем, tsc этот момент изрядно оптимизировал по сравнению с HPET и PIC)
б) если говорить про юзерспейс, то обращение к часам происходит через отдельный вызов сисколла (а значит привет, переключение контекста). Этот момент, впрочем, тоже в современных системах сильно оптимизирован за счёт vdso.

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

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

100. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от uis (??), 17-Янв-24, 12:06 
TSC раком ставит процессор. А если виртуализация включена - то вообще бяда - происходит вызов в гипервизор.
Ответить | Правка | Наверх | Cообщить модератору

128. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от n00by (ok), 17-Янв-24, 15:38 
> TSC раком ставит процессор.

The RDTSC instruction is not serializing or ordered with other instructions. It does not necessarily wait until all
previous instructions have been executed before reading the counter. Similarly, subsequent instructions may begin
execution before the RDTSC instruction operation is performed.

Осталось понять, кто тут процессор.

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

135. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +1 +/–
Сообщение от Аноним (135), 17-Янв-24, 17:32 
> если говорить про юзерспейс, то обращение к часам происходит через отдельный вызов сисколла

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

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

43. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +2 +/–
Сообщение от Аноним (43), 17-Янв-24, 02:24 
>> 2) Смотрение на часы никогда не было какой-то особо простой и дешевой операцией...
> Почему?

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

И вот у гражданина - 20% времени интересного ему сегмента кода - вот - смотрение на часы оказалось. Это ему и не понравилось.

Для юзермода все еще суровее, кернел аж хакает (!!!) юзермод процессы в самом прямом смысле слова - вгружая самым первым в адресное пространство "виртуальный" .so (vDSO) с оверрайдом ряда функций системной либы, в том числе и - вот - смотрение на часы. С более резвой реализацией. В юзермоде это еще более дорогая операция для соответствия поведения "часиков" ожиданиям програмеров и стандартам. Кернел может, вот, заоверлоадить локальной местечковой реализацией, если полагает что умеет это лучше либсы. От хорошей жизни это ессно не делают.

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

137. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от Аноньимъ (ok), 17-Янв-24, 18:33 
Нет, то что следить за временем это не просто совсем с кучей камней - это мне понятно.
То есть как ядро свои часы считает это одно, но, смотреть на часы ядра, которые по идее просто инт в памяти - это другое.
Ответить | Правка | Наверх | Cообщить модератору

168. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –1 +/–
Сообщение от Аноним (-), 22-Янв-24, 00:21 
> Нет, то что следить за временем это не просто совсем с кучей
> камней - это мне понятно.
> То есть как ядро свои часы считает это одно, но, смотреть на
> часы ядра, которые по идее просто инт в памяти - это другое.

Так может сказать только тот кто никогда не пробовал это или что-то отдаленно напоминающее заимплементить сам.

Например - это в общем случае не "просто читает int". Если записывает кто-то другой, начинает волновать кеширование и атомарность чтения. Иначе "просто читая int в памяти" однаждо можно читануть нечто странное. При том - это именно фигня из разряда "раз в год и палка стреляет", так что удачи в дебаге.

А если вон то учесть - даже одно только это само по себе - уже несколько более дорогая и сложная операция чем "просто чтение int из памяти".

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

170. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от Аноньимъ (ok), 22-Янв-24, 10:44 
Нельзя. Запись и чтение атомарные.

И вон в тех цп время вообще в отдельном регистре, как и должно быть.

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

171. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –1 +/–
Сообщение от n00by (ok), 22-Янв-24, 14:22 
> Нельзя. Запись и чтение атомарные.

Пора бы уже начать хоть что-то понимать в теме, прежде чем писать.


#ifndef _M_AMD64
/*
 * @implemented
 */
VOID
NTAPI
KeQuerySystemTime(OUT PLARGE_INTEGER CurrentTime)
{
    /* Loop until we get a perfect match */
    for (;;)
    {
        /* Read the time value */
        CurrentTime->HighPart = SharedUserData->SystemTime.High1Time;
        CurrentTime->LowPart = SharedUserData->SystemTime.LowPart;
        if (CurrentTime->HighPart ==
            SharedUserData->SystemTime.High2Time) break;
        YieldProcessor();
    }
}

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

172. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от Аноньимъ (ok), 22-Янв-24, 14:42 
> Пора бы уже начать хоть что-то понимать в теме, прежде чем писать.

Хоть что-то понимаю.

> code

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

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

174. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от n00by (ok), 22-Янв-24, 14:55 
> Ну и что это за муть без единого комментария?

Это понятный каждому системному программисту код с комментарием по существу.

> Вы бы лучше
> процетировали документацию в которой описано почему они делают так, а не
> иначе.

Зачем?

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

175. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от Аноньимъ (ok), 22-Янв-24, 15:16 
А зачем вы мне что-то вообще пишите?

> Это понятный каждому системному программисту код с комментарием по существу.

В глаза смотреть, чтение и запись инта атомарные или не атомарные операции?

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

176. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от n00by (ok), 23-Янв-24, 08:28 
> А зачем вы мне что-то вообще пишите?

Увидел чушь про атомарность чтения. Показал код, решающий проблему.

>> Это понятный каждому системному программисту код с комментарием по существу.
> В глаза смотреть, чтение и запись инта атомарные или не атомарные операции?

Вопросы здесь задаю я. Но смысла спрашивать "при чём тут инт?" не вижу - ответы у меня и так есть.

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

173. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +/–
Сообщение от Аноньимъ (ok), 22-Янв-24, 14:45 
> Если записывает кто-то другой

Никто кроме ядра время устанавливать не должен.

И происходить это не каждую минуту и не каждый час должно.

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

37. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  –1 +/–
Сообщение от Аноним (37), 17-Янв-24, 01:42 
> 2) Смотрение на часы никогда не было какой-то особо простой и дешевой операцией...

Уже не актуально, так как время можно смотреть через vdso.

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

44. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."  +2 +/–
Сообщение от Аноним (43), 17-Янв-24, 02:26 
>> 2) Смотрение на часы никогда не было какой-то особо простой и дешевой операцией...
> Уже не актуально, так как время можно смотреть через vdso.

У того гражданина 20% времени - смотрение на часы оказалось. Вот он и захотел кешировать это дело.

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

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
Добавить, Поддержать, Вебмастеру