История изменений
Исправление I-Love-Microsoft, (текущая версия) :
Ядро вроде как не realtime. Использую SHED_RR (не знаю, может факт поддержки SHED_RR означает что ядро содержит RT-патчи, тут я хз) и приоритет 99, максимальный в системе. Слишком много, это когда «обычно» процесс занимает ну порядка 50-200 микросекунд, а в случае когда это для меня уже сбой - там уже тысячи микросекунд
Делаю вывод, что wait_event_interruptible не спешит «проснуться», то есть большую часть времени, десятки тысяч циклов не происходит задержка, а потом внезапно вылезает большая задержка и у меня всё ломается
Сейчас я переписал один драйвер на while(atomic_read) - жрет процессор конечно, это ожидаемо, но работает. Сейчас и второй драйвер перепишу в данном месте на atomic_t переменные
В принципе, если это будет работать надежно, то на потребление процессора плевать, задача специализированная, лютой эффективности не требуют, ядер свободных много еще. Конечно с wait_queue процессора жрет 3% а тут 50%
Возможно, существует более интеллектуальный способ передать событие о срабатывании IRQ, но быть может все решение, будь то семафоры и прочие примитивы синхронизации в ядре Linux приведут меня к ровно такой же проблеме
Исправление I-Love-Microsoft, :
Ядро вроде как не realtime. Использую SHED_RR (не знаю, может факт поддержки SHED_RR означает что ядро содержит RT-патчи, тут я хз) и приоритет 99, максимальный в системе. Слишком много, это когда «обычно» процесс занимает ну порядка 50-200 микросекунд, а в случае когда это для меня уже сбой - там уже тысячи микросекунд
Делаю вывод, что wait_event_interruptible не спешит «проснуться», то есть большую часть времени, десятки тысяч циклов не происходит задержка, а потом внезапно вылезает большая задержка и у меня всё ломается
Сейчас я переписал один драйвер на while(atomic_read) - жрет процессор конечно, это ожидаемо, но работает. Сейчас и второй драйвер перепишу в данном месте на atomic_t переменные
В принципе, если это будет работать надежно, то на потребление процессора плевать, задача специализированная, лютой эффективности не требуют, ядер свободных много еще. Конечно с wait_queue процессора жрет 3% а тут 50%
Возможно, существует более интеллектуальный способ передать событие о срабатывании IRQ, но быть может все решение, будь то семафоры и прочие примитивы синхронизации в ядре Linux приведут меня в ровно такой же проблеме
Исходная версия I-Love-Microsoft, :
Ядро вроде как не realtime. Использую SHED_RR и приоритет 99, максимальный в системе. Слишком много, это когда «обычно» процесс занимает ну порядка 50-200 микросекунд, а в случае когда это для меня уже сбой - там уже тысячи микросекунд
Делаю вывод, что wait_event_interruptible не спешит «проснуться», то есть большую часть времени, десятки тысяч циклов не происходит задержка, а потом внезапно вылезает большая задержка и у меня всё ломается
Сейчас я переписал один драйвер на while(atomic_read) - жрет процессор конечно, это ожидаемо, но работает. Сейчас и второй драйвер перепишу в данном месте на atomic_t переменные
В принципе, если это будет работать надежно, то на потребление процессора плевать, задача специализированная, лютой эффективности не требуют, ядер свободных много еще. Конечно с wait_queue процессора жрет 3% а тут 50%
Возможно, существует более интеллектуальный способ передать событие о срабатывании IRQ, но быть может все решение, будь то семафоры и прочие примитивы синхронизации в ядре Linux приведут меня в ровно такой же проблеме