The OpenNET Project / Index page

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



Индекс форумов
Составление сообщения

Исходное сообщение
"Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."
Отправлено Аноним, 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 и ряд иных вещей.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, [email protected] (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



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

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