i'm beginning to see my troubles here. (only just now). I have been reading
"writing linux device drivers" and they state some additional properties for
tasklets. These are (page 199-200):
1) a tasklet is guaranteed to run on the cpu that first schedules it. For
better cache behavoir.
2) when a tasklet is disabled, you may still schedule it. It will run asap
after tasklet_enable.
If we also want to enforce these rules we should a) put them in interrupts.h
b) i think we don't escape from using a cpu field and locking it.
Now, i don't know where oreilly got these addition properties from. In fact,
i've been working on the kernel for less then a week and the first two days
were just to setup my cross compiler. I only noticed that my sparcstation LX
didn't boot and that started this of. (oh and i want to see my name in the
changelog someday, just for fun ;).
anyway, don't know were these come from, but i would like to know if we should
enforce them. I'm working on a better patch, which has the above features,
but if we don't support them, no need to wast cycles over them.
This patch i'm working on now removes the tasklet from tasklet_vec[cpu].list
when it is disabled but not after saving smp_processor_id in t->cpu. When the
tasklet is enabled and the tasklet is marked scheduled, the tasklet is added
to the right cpu.
t->cpu is set on first schedule and not reset with additional schedules.
Oh, and i will try to look for races this time ;)
me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/