> 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/