The OpenNET Project / Index page

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



"Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэшированию запросов времени"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Увеличение скорости ввода/вывода на 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 а не слепо откатывать изменения подхайлайтившие проблему.

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

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

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

Оглавление
Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэшированию запросов времени, opennews, 16-Янв-24, 23:42  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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