Long playing threaded interrupt handlers

Long playing threaded interrupt handlers

[Dmitry Torokhov]

HI Thomas,

The threaded IRQ infrastructure that went into the kernel is extremely
helpful, however in the input land there are quite a few devices that
require polling after an IRQ has been raised.

Currently most such drivers, instead of threaded interrupts, still use
[delayed] work to do the polling, and still face the issue of shutting
down interrupt and scheduled work in a raceless way leaving irq enable
counter balanced. Is it allowed to have threaded ISR execute for
extended a amount of time, and do the required polling, provided that
ISR does certain checks to finish promply in case when we unbind the
driver or try to suspend the device?

Thanks.

-- 
Dmitry

Re: Long playing threaded interrupt handlers

[Thomas Gleixner]

On Wed, 2 Jun 2010, Dmitry Torokhov wrote:

> HI Thomas,
> 
> The threaded IRQ infrastructure that went into the kernel is extremely
> helpful, however in the input land there are quite a few devices that
> require polling after an IRQ has been raised.
> 
> Currently most such drivers, instead of threaded interrupts, still use
> [delayed] work to do the polling, and still face the issue of shutting
> down interrupt and scheduled work in a raceless way leaving irq enable
> counter balanced. Is it allowed to have threaded ISR execute for
> extended a amount of time, and do the required polling, provided that
> ISR does certain checks to finish promply in case when we unbind the
> driver or try to suspend the device?

Sure, why not ? The only thing we need to think about is when the poll
is busy polling for a long time, then we need to lower the irq thread
priority to SCHED_OTHER in order not to hog the CPU.

Vs. shutdown: The thread handler needs to be aware of a shutdown
request in it's poll loop, so something like this should work:

handler()
{
	while (work_to_do() && !shutdown) {
	      .....
	}
}

unbind()
{
	shutdown = 1;
	free_irq();
}

Thanks,

	tglx

Re: Long playing threaded interrupt handlers

[Dmitry Torokhov]

On Wed, Jun 02, 2010 at 09:19:21AM +0200, Thomas Gleixner wrote:
> On Wed, 2 Jun 2010, Dmitry Torokhov wrote:
> 
> > HI Thomas,
> > 
> > The threaded IRQ infrastructure that went into the kernel is extremely
> > helpful, however in the input land there are quite a few devices that
> > require polling after an IRQ has been raised.
> > 
> > Currently most such drivers, instead of threaded interrupts, still use
> > [delayed] work to do the polling, and still face the issue of shutting
> > down interrupt and scheduled work in a raceless way leaving irq enable
> > counter balanced. Is it allowed to have threaded ISR execute for
> > extended a amount of time, and do the required polling, provided that
> > ISR does certain checks to finish promply in case when we unbind the
> > driver or try to suspend the device?
> 
> Sure, why not ?

Great, that is what I wanted to hear!

> The only thing we need to think about is when the poll
> is busy polling for a long time, then we need to lower the irq thread
> priority to SCHED_OTHER in order not to hog the CPU.

I don't think the drivers will actively polling for a long time, they
are likely to poll and then sleep for some time (100-200-300 msecs), so
typical loop will be:

handler()
{
	while (!shutdown_or_suspend) {
		poll_device();

		if (all_up)
			break;

		msleep(poll_interval);
	}

	return IRQ_HANDLED;
}

Thanks.

-- 
Dmitry