Help in understanding the tasklets
in [Kernel]
|
Prev: [PATCH 2/6 v2]kernel:audit.c Fix warning: variable 'nlh' set but not used
Next: [PATCH 1/4] procfs: proc_get_sb: consolidate/cleanup root_inode->pid logic
From: Hari LKML on 19 Jun 2010 14:40 After reading some of the books and the codes here is my understanding about the tasklet_action function the function statrs some thing like this 1. If the tasklet is not running in another processor set the Bit TASKLET_STATE_RUN; ��� <<if (tasklet_trylock(t))>> 2. clear the TASKLET_STATE_SCHED bit;������ <<if (!test_and_clear_bit(TASKLET_ STATE_SCHED, &t->state))>> 3. start the tasklet � � <<(��� t->func(t->data))>> Now when the tasklets function is running and the same interrupt is raised again but now handled by a different processor (in a SMP system) the tasklet is now scheduled in a different processor (because the TASKLET_STATE_SCHED is already cleared in step 2) and there are every chance of the same type of� taklet running concurently in different processors thus braking the promise that same types of tasklets do not ever run simultaniously. I think i have misunderstood one or the other concept so please correct me and help me in understanding the Linux Kernel code more clearly. Please personally CC me all answers/comments posted to the list, to my mail id hari.lkml(a)gmail.com. Hari -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Slaby on 23 Jun 2010 18:10
On 06/19/2010 08:36 PM, Hari LKML wrote: > After reading some of the books and the codes here is my understanding > about the tasklet_action function > > the function statrs some thing like this > > 1. If the tasklet is not running in another processor set the Bit > TASKLET_STATE_RUN; <<if (tasklet_trylock(t))>> > 2. clear the TASKLET_STATE_SCHED bit; <<if (!test_and_clear_bit(TASKLET_ > STATE_SCHED, &t->state))>> > 3. start the tasklet <<( t->func(t->data))>> > > > Now when the tasklets function is running and the same interrupt is > raised again but now handled by a different processor (in a SMP > system) the tasklet is now scheduled in a different processor (because > the TASKLET_STATE_SCHED is already cleared in step 2) > and there are every chance of the same type of taklet running > concurently in different processors thus braking the promise that same > types of tasklets do not ever run simultaniously. > > I think i have misunderstood one or the other concept so please > correct me and help me in understanding the Linux Kernel code more > clearly. But tasklet_trylock will return 0 when t->func is running on another processor already because of step 1. Thus the tasklet gets to the end of the tasklet list and is tried again later. -- js -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |