what is the importance of enabling the interrupts while bottom halves are running?
 

Hi,

I was going through the bottom half(tasklet, workqueue, softirq) code in linux.
All have one thing common that if an instance of deferred tasklet/work is pending, the new instance of deferred tasklet/work is ignored.

For an instance if a work is queued in workqueue from the ISR and before the work has been served; the same interrupt comes again it will try to queue the work again, but schedule_work() function checks that if already work is pending, it ignores the new.

Then what is the advantage of enabling the interrupt in bottom halves?

Please somebody answer this I tried a lot but i didnot get the answer.

If you don't enable the interrupt, you are throwing away information. Disabling & Re-enabling interrupts on process exit is a more involved business to code than the simple check when an interrupt comes. And these days there is interrupt sharing, so the option of disabling an interrupt is not always wise.

If you don't enable the interrupt, you are throwing away information

But any how if we are not queuing or scheduling the new instance of bottom half, so it is same as throwing as information. Isn't so?

And what if interrupt line is not shared then is there any advantage by enabling the interrupt?

Most drivers queue up the new work. What driver is throwing it away?

/* Returns %false if @work was already on the kernel-global workqueue and %true otherwise */

static inline bool schedule_work(struct work_struct *work)
{
return queue_work(system_wq, work);
}

As mentioned in "Understanding Linux Kernel" also,
"queue_work() checks whether the function to be inserted is already present in the work queue (work->pending field equal to 1); if so, terminates." (Reference: Work queue functions in chapter 4)

Please correct me know If I understood it wrong.

It returns 0 if that specific struct is already queued, not if other work is queued.

yes, then its mean the same struct work is not going to queued. isn't it?

For an instance, schedule_work(&jiq_data.work) have queued the work. While the previous queued work is pending, if an interrupt handler call schedule_work(&jiq_data.work) then it will not queue.

Am I right?

Only if it always uses the same struct every time. Most drivers use a preallocated pool and can queue up new items until the bottom half catches up. Your storage would not work very well if the disk interrupt dropped read data because it had not finished copying the last data.

Thanks smallpond.

It is helpful.

Could you point out any driver to understand it better?

The QLogic fibre channel interrupt routines seem to each have a for loop that pulls up to 50 things at a time from the response queue and submits them to a workqueue for offlevel processing.

http://lxr.free-electrons.com/source...2xxx/qla_isr.c

An interrupt is basically a signal to the kernel that a device requires attention "soon." The first thing to do is to gather information from the interrupting device, which must be done with interrupts disabled. But, once that has been done, we want to open interrupts up again right away.

If the device "pesters" us with additional interrupts before we've had a chance to attend to its needs, that's redundant (and a potential flood), so the interrupt is ignored. Soon enough, the other half will run and silence the device.