Messages in this thread | | | Date | Wed, 23 Feb 2000 10:24:22 -0500 (EST) | From | Jeff DeFouw <> | Subject | Re: tasklet race condition |
| |
On Wed, 23 Feb 2000 kuznet@ms2.inr.ac.ru wrote:
> Task is marked as SCHEDuled and it is not on this list when > it is already scheduled on another CPU.
Hrm.. oops. I should have noticed that. The tasklets in my brain must have stopped running also. :)
> It is very simple machine: SCHED flag means that tasklet is scheduled > or about to be scheduled on some CPU. If it is set, the tasklet > is already scheduled and will run soon on some cpu.
"will run soon" is what it should be. What's happening is that the actual case becomes "will never run".
> If you want to test it, check not only this list but all the lists > for all the CPUs. [It is dangerous! You have to add new spinlock > to make this]
That's what I'll do then. I'll figure something out. I should add the cpu id to the debug messages for starters.
> > tasklet never runs, and the other time it only runs once or twice. > > Exactly. Doing for (i=0;i<12;i++) mark_bh(xx) you will have > BH running once, rather than 12 times. Tasklets are not different > in this sense, they batch events.
Well, not exactly. What's really happening is infrequent_irqhandler() {...; mark_bh(xx); ...;} where infrequent_irqhandler gets called many times per second over at least a few seconds up to infinity. I guess that's close to a for (;;) mark_bh(xx) with interrupts in the loop. I'm aware that they batch. The problem is at some point they get lost. More than 5 minutes will go by without the scheduled tasklet ever running and it's queue status never changes.
-- Jeff DeFouw <defouwj@purdue.edu>
- 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/
| |