The OpenNET Project / Index page

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



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

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

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



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

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