> The point is that to get delayed for 210 usec you must mark the bh with in
> a window of time that is near zero (the faster the CPU the smaller the
> window).
Err, I didn't want to say 210 usec, but 1 jiffy, i.e., 10 msec on i386. Sorry.
And the window I mean is NOT the one between get/clear_active_bhs(). Look:
Processor A Processor B
----------- -----------
enters do_irq
handles irq
marks some bh
gets to run_bottom_half()
acquires both locks
reads active_bhs enters do_irq
starts executing them handles irq
marks some bh
gets to run_bottom_half()
does not get the lock, so it exits
releases both locks and exits exits from do_irq
exits from do_irq.
So, the bh marked by B gets delayed until the next interrupt arrives,
and is not executed ASAP.
I know that bhs are expected to be delayed in principle (that's why they
exist), but this delay is not really necessary and is caused by design.
Some systems, like AmigaOS and it's exec.library avoid this problem by
strobing the software irq line, which ensures that you always enter the
soft irq handler ASAP after it has been triggered. That's why I asked why
m68k does not use this as well...
>> That's not what I had in mind. I wrote about soft/hardirq_trylock().
>> Isn't there a (however slight) chance that alway some other processor
>> than the one in do_bottom_half is holding one of these lock? I am afraid
>> there is...
>
> Hmm, I trust that start_bh_atomic() is SMP safe (if it isn't we should
> have noticed that because start_bh_atomic() is mainly used to close the
> window for SMP races ;). But can you show me the window you seen with a
> simple scheme?
I was not speaking about races this time. My idea was about theoretical
chance that some processors execute normal non-irq stuff, some hard-irq
stuff, but none of them executes soft-irq stuff because the double locking
always prevents it. Just forget it, it's too artificial.
BTW, current do_IRQ() does not use get_active_bhs() macro.
BTW2, the comment at run_bottom_halves() is obsolete.
Hmm, I suggest that we just stop this discussion, as it does not lead
anywhere anyway and nobody else seems to think this is an issue...
Patrik
-
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/