Messages in this thread | | | Date | Sat, 13 Mar 1999 11:58:10 -0800 (PST) | From | "B. James Phillippe" <> | Subject | Re: Query about task Queues ! (fwd) |
| |
On Sat, 13 Mar 1999, G Jalaja Devi wrote:
> In case of using task queues for deferred processing in an interrupt > handler(isr), A task statically defined as type tq_struct is used to > queue for dpc by the call to queue_task(). Meanwhile, if another > interrupt occurs, the same task can obviously be not queued again as long > as the previously queued task is not scheduled. Otherwise the scheduler > will go in an infinite loop. How do you guarantee in an isr that the > previously queued task is already scheduled?
I had this same question myself. I added a bottom half to a (proprietary) protocol-accelerator driver for 2.0 using tq_immediate.
> And obviously, allocating memory for a tq_struct in an isr is not > recommended. Or should I maintain a list of tasks initially allocated , > and pick up an unused one everytime an interrupt occurs.?
Currently, I just allocate a new struct GFP_ATOMIC in the ISR. But I was worried about performance as well. I already did a free-list for another structure in the driver, so I think I will do the same for the task struct. You may wish to build a list of the linked structures at init_module time, and have "checkout/checkin" functions that use them off the top. I wrote two very small, inline functions (with locking to protect the queue access) that checkout an item or return one to the list. You can also implement dynamic growing of the list such that if the list is ever exhausted, you add another X elements. I think pruning is a little more challenging.
Good luck, -bp -- B. James Phillippe . bryan@terran.org Software Engineer, WGT Inc. . http://www.terran.org/~bryan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |