Есть некий драйвер, который ловит прерывания с периодичностью несколько десятков миллисекунд, и судя по time stamp в логе dmesg, делает это очень надежно и регулярно, очень точно с точностью до десятков микросекунд
В ядре используется wait_queue_head_t, в обработчике прерывания wake_up_interruptible, далее wait_event_interruptible, после чего userspace процесс просыпается
Вот иногда в 1% случаев, оно делает это слишком поздно, мне надо успеть за 100-150 мкс, а оно в такие моменты может даже до миллисекунды скакнуть это время ожидания. А когда всё хорошо, оно успевает за 50 в среднем мкс, иногда за 115 что тоже нормально
Пробовал ставить nice -n 0, лочить процесс на ядро taskset -c. И ничего не помогло не улучшило ситуацию
Но программа работает и с еще одним драйвером, который тоже завязан на прерывания, и они тоже приходят очень точно и хорошо. И там тоже проблема что иногда изредка программа просто не просыпается несколько миллисекунд, чтобы отреагировать
Я так понимаю, это ядро просто не всегда хочет будить процесс в userspace?
Уже и nice использовал, что еще можно попробовать, чтобы сказать системе - вот это важные процессы в системе, их нельзя обижать и выгружать, вытеснять и так далее? Что мне все равно что будет со всеми прочими программами в системе
Как объяснить - вот эта программа это VIP, это священный процесс, он всегда должен быть бодряком. Ядро ради него отдам, два, три! Как то так
