Что происходит в ядре, когда драйвер делает udelay?

grep -R -n udelay Documentation/

:)

В теории это busy-wait, то есть должен занимать, да.

Миграция на другое ядро возможна, RT задачи преемтятся.

А драйвер априори RT задача? А аффинити для дров не бывает? А чего произойдёт по прерыванию от таймера? А что будет если на этом же ядре запущен RT поток в юзерспейсе?

https://lkml.org/lkml/2017/10/31/610

P.S. Для тру - всё плохо

Мда.

страсти-то какие

А ведь есть же nonstop_tsc.

а вдруг ТС не для писюка пишет дрова

Сраные мобилы затормаживают линуксовое ядро.

А драйвер априори RT задача?

Драйвер вообще не задача.

А аффинити для дров не бывает?

Нет. Аффинити бывает только для нитей.

А чего произойдёт по прерыванию от таймера?

То, что должно.

О! А тебя не банили случайно? Чет мне казалось я видал твой ник перечёркнутым…

За пояснения спасибки, но для полноты картины - а как тогда планируется код драйвера?

То, что должно.

Т.е. вызов планировщика, или есть варианты?

Последние месяцы я хожу на ЛОР только тогда, когда меня кастуют. Но меня не банили.

как тогда планируется код драйвера?

Строго говоря, код драйвера не планируется никак. Никакой код вообще не планируется - планируется нить исполнения. Нити, исполняющие код драйвера, планируются на общих основаниях, если не отключили вытеснение и не впали в uninterruptible sleep.

Т.е. вызов планировщика, или есть варианты?

Т.е. вызов top half обработчика таймерного прерывания. Дальше возможны варианты - насколько я знаю, в обычном ядре top half ставит заявку на исполнение bottom half, а в PREEMPT_RT top half (если она так называется - не помню точно) разблокирует нить обработчика, и эта нить планируется на общих основаниях.

так я чего-то не понял: в современном компьютере ядро жжет кучу тактов вхолостую просто для того, что бы удовлетворять капризному железу, которое хочет что бы в него засунули байт не раньше, чем через N микросекунд?

в современном компьютере ядро жжет кучу тактов вхолостую просто для того, что бы удовлетворять капризному железу, которое хочет что бы в него засунули байт не раньше, чем через N микросекунд?

Если коротко и неточно, то да. У тебя есть другие предложения? При том, что железо не будет работать (незаметно так), если «сунуть в него байт» раньше, чем через N мкс.

P.S. А еще есть MMIO на PCI.

При том, что железо не будет работать (незаметно так), если «сунуть в него байт»

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

Например, можно попробовать сделать планировщик таких посылок в ядре, который постоянно будет что-то слать, расставляя такие посылки по очереди во времени.

Но полагаю, что это не очень интересно, потому что накладные расходы на его управление будут выше, чем эти микросекунды.

Т.е. мы продолжаем платить за гибкость таким перерасходом ресурсов.

При том, что железо не будет работать (незаметно так), если «сунуть в него байт»

это наверное поправить уже никак

В общем, да. Приходится работать с тем, что есть.

накладные расходы на его управление будут выше, чем эти микросекунды.

Поэтому короткие задержки и делаются через занятое ожидание.

Т.е. мы продолжаем платить за гибкость таким перерасходом ресурсов.

Я думаю, что в среднепотолочном случае «устройству нужны паузы между записями» мы платим не за гибкость, а за дешевизну устройства или процесса разработки этого устройства. В MMIO - пожалуй да, за гибкость.

Я тебе больше скажу - отдельные личности и в юзерспейсе в софт риалтайме таким балуются, например в угоду лучшего и более честного распределения ресурса между равноправными сущностями, или что бы подгадать под определённое событие. У busy wait точность выше чем у nanosleep, даже если всё ядро в твоём распоряжении, притом может до смешного доходить - в случае busy wait спишь с точностью до стоимости вызова gmtime(примерно 100ns на десктопном железе вроде) или rdtsc + немного арфиметики(что почти то же самое на самом деле), а с системным вызовом и ядром в наличии промахиваться на 5-10us.

Ещё, люблю приводить примеры типа SO_BUSY_POLL, прям запала мне в душу эта опция.

так я чего-то не понял: в современном компьютере ядро жжет кучу тактов вхолостую просто для того, что бы удовлетворять капризному железу, которое хочет что бы в него засунули байт не раньше, чем через N микросекунд?

в общем - нет, а в частности есть ситуации когда по-другому нельзя т.н. atomic context когда недопустимо перепланирование - это обработчики аппаратных прерваний (top half), контекст softirq, тасклеты

https://www.kernel.org/doc/Documentation/timers/timers-howto.txt

для остальных случаев есть семейство sleep

есть ситуации когда по-другому нельзя т.н. atomic context когда недопустимо перепланирование

Заданный вопрос не об этом.

https://www.kernel.org/doc/Documentation/timers/timers-howto.txt

NON-ATOMIC CONTEXT:

	SLEEPING FOR «A FEW» USECS ( < ~10us? ):
		* Use udelay

Да и накладные расходы usleep_range выглядят запретительными на десятках микросекунд.

Заданный вопрос не об этом

начальный - да, но я отвечал не на него

Да и накладные расходы usleep_range выглядят запретительными на десятках микросекунд

зависит от процессора

On slower systems, (embedded, OR perhaps a speed-stepped PC!) the overhead of setting up the hrtimers for usleep *may* not be worth it

японцы умудрялись выполнять задачи с периодичночстью 10 мкс на пентиум 2 на модифицированном ядре

http://art-linux.sourceforge.net/

450 MHz это же 1/450 мкс

Да и накладные расходы usleep_range выглядят запретительными на десятках микросекунд

зависит от процессора

Конечно. Думаю, на некоторых и сотни микросекунд будут невыгодны.

японцы умудрялись выполнять задачи с периодичночстью 10 мкс на пентиум 2 на модифицированном ядре

http://art-linux.sourceforge.net/

Эти «задачи» не были полноценными задачами Linux. Такие задачи да, можно и помногу раз за микросекунду.

450 MHz это же 1/450 мкс

Да, Капитан. А 100МГц - это 1/100мкс. Но время переключения контекстов на 100МГц Pentium - десятки мкс.

Но время переключения контекстов на 100МГц Pentium - десятки мкс.

на современных процессорах - 1..2 мкс

https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-ove...

Но время переключения контекстов на 100МГц Pentium - десятки мкс.

на современных процессорах - 1..2 мкс

И даже чуть больше, как отмечает и сам Эли. Что делает реализацию коротких задержек через планировщик непрактичной, как и было сказано выше (вопрос вымывания кэша даже не рассматриваем)..

Что делает реализацию коротких задержек через планировщик непрактичной

да это понятно, мне вообще непонятно - нафига нужны короткие задержки, Linux не микроконтроллерная ОС.

мне вообще непонятно - нафига нужны короткие задержки

Выше сказано - некоторые устройства их требуют.

Linux не микроконтроллерная ОС

Да где его только нет... Сделали же ucLinux.

Выше сказано - некоторые устройства их требуют

ну раз васян сказал - так оно и есть :)

Сделали же ucLinux

гадость какая-то. Кто-то сэкономил и сделал CPU без MMU с богатой периферией, вопрос - нахер это чудо нужно если за те же деньги можно взять нормальный с MMU ?

Выше сказано - некоторые устройства их требуют

ну раз васян сказал - так оно и есть :)

Это да. Куда тебе спорить с васянами.