Re: tasklets in 2.4.6

[Jeff Garzik <jgarzik@mandrakesoft.com>]

Ville Nummela wrote:
> In kernel/softirq.c, line 178:
> 
>                 if (test_bit(TASKLET_STATE_SCHED, &t->state))
>                         tasklet_schedule(t);
> 
> What's the idea behind this line? If the tasklet is already scheduled,
> schedule it again? This does not make much sense to me.
> 
> Also, few lines before:
> 
>                        if (test_bit(TASKLET_STATE_SCHED, &t->state))
>                                 goto repeat;
> 
> Here we'll loop forever if the tasklet should schedule itself.

hmmm, it looks almost ok to me.

The tasklet is locked before the "repeat" label, so any tasklet
scheduling itself will set the bit, but NOT actually schedule iteself. 
For this see the tasket_schedule code, for the case where the bit is not
set, but the tasklet is locked.

The first statement above schedules the tasklet if the bit was set while
the tasklet was locked.  The second statement, as the comment right
above it indicates, causes the tasklet to repeat itself.

The only thing that appears fishy is that if the tasklet constantly
reschedules itself, it will never leave the loop AFAICS.  This affects
tasklet_hi_action as well as tasklet_action.

> repeat:
>                 if (!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state))
>                         BUG();
>                 if (!atomic_read(&t->count)) {
>                         local_irq_enable();
>                         t->func(t->data);
>                         local_irq_disable();
>                         /*
>                          * One more run if the tasklet got reactivated:
>                          */
>                         if (test_bit(TASKLET_STATE_SCHED, &t->state))
>                                 goto repeat;
>                 }


	Jeff


-- 
Jeff Garzik      | A recent study has shown that too much soup
Building 1024    | can cause malaise in laboratory mice.
MandrakeSoft     |