[SOLVED] what is the importance of enabling the interrupts while bottom halves are running?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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)
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.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.