LINUX.ORG.RU

Прерывания с периодом 1мс


0

0

Девайс генерит с pci шины прерывания с периодом 1мс. Мне нужно гарантировать их обработку и непропуск в течение этого периода. Если не грузить комп другими задачами, то проблем не возникает. Хотелось бы уточнить как это правильно сделать. И вообще возможно поднимать приоритет прерывания и каким образом?


> И вообще возможно поднимать приоритет прерывания и каким образом?

нет, нельзя.

> Мне нужно гарантировать их обработку и непропуск

ну так завершайте irq handler по-быстрому, а все
нетривиальные действия в softirq.

> Если не грузить комп другими задачами,

не понял. прерывание потому так из называется,
что прерывает текущий процесс.

idle ★★★★★
()

1 мс - это сколька в килогерцах? :-)
Мне нада было собирать данные с частотой 8 Кгц, используя RTAI (www.rtai.org), при любом запущеноом кол-ве jvm и updatedb ничего не терялось. Единственное, нада было выключить DMA у харда.
Удачи

tukan
()
Ответ на: комментарий от idle

>> Если не грузить комп другими задачами,

>не понял. прерывание потому так из называется,
>что прерывает текущий процесс.

Есть такое понятие как приоритет прерывания, и если по каким то пречинам
прерываний с большим приоритетом генерится много в малый промежуток времени, то твое просто будет ждать.

tukan
()
Ответ на: комментарий от tukan

tukan:
> > > Если не грузить комп другими задачами,
> >
> > не понял. прерывание потому так из называется,
> > что прерывает текущий процесс.
>
> Есть такое понятие как приоритет прерывания, и если по каким то пречинам
> прерываний с большим приоритетом генерится много в малый промежуток
> времени, то твое просто будет ждать.

при получении прерывания linux немедленно делает ack контроллеру,
и (если не SA_INTERRUPT) sti. никто никого ждать не будет. здесь
мы говорим о приоритете аппаратном, кстати.

так что менее приоритетное в этом смысле прерывание будет ждать
только до тех пор, пока do_IRQ() не сделает desc->handler->ack(irq).
замечу еще раз, это аск контроллеру прерываний, не девайсу, который
его выставил. и это делается еще до входа в обработчик прерывания.

idle ★★★★★
()
Ответ на: комментарий от idle

>так что менее приоритетное в этом смысле прерывание будет ждать
>только до тех пор, пока do_IRQ() не сделает desc->handler->ack(irq).

Может как раз это и обясняет большую( или недопустимую) латентность.
Повесь обработчик прерывания на IRQ 7, и пусть девайс какой нибуть
подергает его с частотой 8Кц, пока машина не нагружена, вроде все в порядке, запусти updatedb, и начнутся потерянные прерывания.

tukan
()
Ответ на: комментарий от idle

> ну так завершайте irq handler по-быстрому, а все нетривиальные действия в softirq.

А как ими пользоваться, где про это почитать и примеры? А то я так и не смог найти про них инфу :-/

Spectr ★★★
()
Ответ на: комментарий от tukan

> > так что менее приоритетное в этом смысле прерывание будет ждать
> > только до тех пор, пока do_IRQ() не сделает desc->handler->ack(irq).
>
> Может как раз это и обясняет большую( или недопустимую) латентность.
> Повесь обработчик прерывания на IRQ 7, и пусть девайс какой нибуть
> подергает его с частотой 8Кц, пока машина не нагружена, вроде все
> в порядке, запусти updatedb, и начнутся потерянные прерывания.

нет. фактически прерывания в linux не имеют приоритетов.
этот период ожидания (до ack) для прерывания с любым номером
одинаковый, и в это время прерывания запрещены вообще.

теряются они, скорее всего, из-за того, что не включен DMA
и interrupt unmasking. любой код, который запрещает прерывания
на период, больший чем 1/8Kц может быть причиной потери irq.

можете просто переключать консоль под framebuffer, и посмотреть,
сколько у вас потеряется. безо всякой нагрузки.

idle ★★★★★
()
Ответ на: комментарий от idle

>> Если не грузить комп другими задачами,
>
> не понял. прерывание потому так из называется,
> что прерывает текущий процесс.

Я имел в виду kernel-space. Понятно, что user-space прерывается.


> ну так завершайте irq handler по-быстрому, а все нетривиальные
> действия в softirq

В этом месте хотелось бы узнать подробности.


> теряются они, скорее всего, из-за того, что не включен DMA
> и interrupt unmasking
^^^^^^^^^^^^^^^^^^^^^^^^^^

и про это тоже, плиз

sts
() автор топика

Для большей уверенности посади обработчик на отдельную линию (если есть возможность). Больше пока ничем помочь не могу, но у меня проблем не возникало... Если что, то я karakozov@inbox.ru. У меня тоже есть вопросы, пиши поговорим.

karak
()
Ответ на: комментарий от sts

> > действия в softirq
>
> В этом месте хотелось бы узнать подробности.

то, что раньше называлось bottom half. смотреть
tasklet_schedule(). кроме того, есть workqueues,
вы вообще получаете процесс контекст, kernel_thread()
опять же.

> > и interrupt unmasking
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^
> и про это тоже, плиз

man hdparm. без этого флага и без DMA driver ide
может запрещать прерывания оооочень надолго.

idle ★★★★★
()
Ответ на: комментарий от cvv

> А перепрограммирование шедуллера случайно не поможет???

не понимаю что вы имеете в виду. планировщик-то при чем???

idle ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.