On Friday 15 June 2007 20:09, Dan Miller wrote:
> I have a driver (running under kernel 2.6.11.4-20a) which manages a
> fairly large number of transmitter and receiver cards. I'm having a
> major latency problem in the receive side of our testbed, which (at the
> moment) has 8 receive cards and 2 transmit cards. The interrupt function
> in each case uses schedule_work() to schedule later handling of interrupt
> data (as usual).
>
> I'm finding that, when the system is under full load, the tx_done tasks
> end up being handled sequentially with the RX tasks, and thus end up
> getting excessivly delayed in handling, which is causing an artificial
> bottleneck in our entire data chain. I need to find some way of
> separating the handling of the TX events from the handling of the RX
> events.
>
> I was attempting to switch to tasklets for the TX interrupt handlers.
Is there any special reason for which you need workquues/tasklets? AFAIK most
network drivers are doing fine without them.
> However, when I try to instantiate a tasklet for each device:
>
> struct my_device {
> ...
> struct tasklet_struct my_tasklet;
> ...
> } ;
>
> // in driver-init function:
> tasklet_init(&device->my_tasklet, my_tasklet_func,
> (unsigned long) device);
> // I also tried manually setting the my_tasklet fields,
> // rather than depending upon this function,
> // with the same result.
>
> // in the interrupt function:
> tasklet_schedule(&device->my_tasklet);
>
> void my_tasklet_func(unsigned long datum)
> {
> printk("message\n") ;
> }
>
> This all looks normal, right?? But when I run it, the computer
> locks up when tasklet_schedule() is reached!!
>
Yep, that looks OK to me.
You could use sysrq to force a stack dump and maybe get something usefull out
of it.
tavi
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
