On Mon, Oct 12, 2009 at 10:52 AM, Joel Fernandes <agnel.joel@xxxxxxxxx> wrote:
> Hi Peter,
>
> Thanks for your response. I think I didn't frame my question properly.
> I know how softirqs and tasklets work but what I don't is how do they
> function in queuing situations where the rate at which the
> softirq/tasklet is raised is faster than the rate at which they are
> scheduled/run.
your envisaged scenario will not happened, because, like what your
previous email said, tasklet queuing is not like the normal linked
list queuing. when u schedule a tasklet for execution, a flag is
set, so that softirqd will execute it later. but if u call schedule
multiple times, there is no difference, because the flag has already
been set - so it effectively only execute once (your previous email).
360 void __tasklet_schedule(struct tasklet_struct *t)
361 {
368 raise_softirq_irqoff(TASKLET_SOFTIRQ);
370 }
371
so if u want to make sure the previous scheduled tasklet actually
comleted before adding a new one, explicitly trigger the tasklet's
action, before calling tasklet_schedule() again - while being wrapped
in tasklet disabled mode, for example, in drivers/atm/eni.c's
eni_send() function:
2064 ATM_SKB(skb)->vcc = vcc;
2065 tasklet_disable(&ENI_DEV(vcc->dev)->task);
2066 res = do_tx(skb);
2067 tasklet_enable(&ENI_DEV(vcc->dev)->task);
2068 if (res == enq_ok) return 0;
2069 skb_queue_tail(&ENI_VCC(vcc)->tx->backlog,skb);
2070 backlogged++;
2071 tasklet_schedule(&ENI_DEV(vcc->dev)->task);
the do_tx() is the actual function that writes to the PCI hardware for
sending out data. and line 2068-2070 is the queuing of the next SKB
ready to be executed - after tasklet_schedule() has scheduled the
tasklet to be executed inside the softirqd event loop.
in this way, every tasklet_schedule() will effectively mapped to
different action event.
not sure if my analysis is correct? criticism welcomed.....
>
> Thanks,
> -Joel
>
> On Mon, Oct 12, 2009 at 12:45 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
>> On Mon, Oct 12, 2009 at 12:24 PM, Joel Fernandes <agnel.joel@xxxxxxxxx> wrote:
>>> Hi Friends,
>>>
>>> I have a question about tasklets:
>>>
>>> I understand that they are used to defer work during interrupt
>>> handling. What I don't understand is - how do they handle queuing of
>>> deferred work?
>>
>> via softirq mechanism: look at kernel/softirq.c:
>>
>> 55 static struct softirq_action softirq_vec[NR_SOFTIRQS]
>> __cacheline_aligned_in_smp;
>> 56
>> 57 static DEFINE_PER_CPU(struct task_struct *, ksoftirqd);
>> 58
>> 59 char *softirq_to_name[NR_SOFTIRQS] = {
>> 60 "HI", "TIMER", "NET_TX", "NET_RX", "BLOCK", "BLOCK_IOPOLL",
>> 61 "TASKLET", "SCHED", "HRTIMER", "RCU"
>> 62 };
>>
>>
>> From above, we can see that tasklet is just but one of the softirq
>> (software interrupt) todo list. Tasklet are implement by "HI" for
>> HI_SOFTIRQ (high priority tasklet) and TASKLET. To indicate a
>> software interrupt occurring u used raise_softirq() - then the action
>> will be executed later by softirqd (after wakeup_softirqd() is
>> called).
>>
>> The loop to go through each item on the tasklet todo list is here:
>>
>> 398
>> 399 static void tasklet_action(struct softirq_action *a)
>> 400 {
>> 401 struct tasklet_struct *list;
>> 402
>> 408
>> 409 while (list) {
>>
>> 414 if (tasklet_trylock(t)) {
>> 415 if (!atomic_read(&t->count)) {
>> 416 if
>> (!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state))
>> 417 BUG();
>> 418 t->func(t->data);
>> 419 tasklet_unlock(t);
>> 420 continue;
>> 421 }
>> 422 tasklet_unlock(t);
>> 423 }
>>
>>> Specially with tasklets, if a tasklet is re-scheduled before the
>>> previous scheduling of the same tasklet has a chance to run, then the
>>> tasklet is executed only once - not twice. But what if the work that
>>> the tasklet was supposed to do in these 2 instances were different and
>>> that its function was supposed to be passed 2 different structures?
>>> Shouldn't the tasklet be executed twice with these 2 structures?
>>>
>>> I know that work queues are there for that, but how do device drivers
>>> that use tasklets cope with the above?
>>>
>>> Thanks,
>>> -Joel
>>
>>
>> --
>> Regards,
>> Peter Teoh
>>
>
--
Regards,
Peter Teoh
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
