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

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

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

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

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

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

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

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

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

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

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

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