Re: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...)

Richard Gooch (rgooch@atnf.csiro.au)
Tue, 22 Sep 1998 21:01:34 +1000

Keith Owens writes:
> On Tue, 22 Sep 1998 17:57:00 +1000,
> Richard Gooch <rgooch@atnf.csiro.au> wrote:
> >Keith Owens writes:
> >> On Tue, 22 Sep 1998 17:27:36 +1000,
> >> Richard Gooch <rgooch@atnf.csiro.au> wrote:
> >> >The simple rule: "if you haven't registered/marked active a BH, then
> >> >you aren't going to trigger BH processing, so don't worry about it"
> >> >seems like the right thing.
> >>
> >> Something that has been puzzling me about all of this selective do
> >> or don't mark_bh(). If there is data to be processed then the BH
> >> must be run eventually. When does the interrupt handler finally
> >> decide to mark_bh()? The obvious way is on a later interrupt but
> >> what happens if no more interrupts arrive? Extremely unlikely but
> >> possible.
> >
> >You'll get another interrupt 10 ms later at worst. You'll also run
> >BH's on return from syscall, IIRC.
>
> But only if the interrupt handler did mark_bh() in the first place.
> True, return_syscall will call do_bottom_half() if *any* BH bit is set
> but do_bottom_half() only calls BH routines if their *specific* bit is
> set. Something has to mark_bh(specific bit) at some stage or the data
> for that bit will just sit there.

Eh? do_bottom_half() will run *any* BH that is marked. So what's the
problem? Anything that registers a BH will of course have to mark it:
that's the whole point.

> >Besides, it seems to me that the argument has been over not processing
> >BH's in after running an interrupt handler *which won't register/mark
> >active a BH in the first place*. The so-called "fast interrupts" that
> >people still seem to believe in.
>
> If one is not registered that is fine, no work to do anyway, lose a few
> cycles running the bit map. But if a BH has been registered then
> sooner or later, something has to mark_bh(). It is all very well
> delaying a BH until (say) 10 interrupts have arrived but what if we
> only get 9 interrupts? There has to be a bounded delay on running any
> delayed BH.

Ah, I think I see what you're driving at. I think you've misunderstood
what I mean. Any interrupt handler that registers a BH should mark
its BH. Always.
My point is that "fast" handlers that don't set up work to be done in
a BH won't be marking any BH's. Hence "fast" handlers don't need to
ask for SA_INTERRUPT to avoid BH processing.

In any case, this is academic, since do_bottom_half() is always called
upon return from interrupt. "Fast" handlers can't avoid it.

Regards,

Richard....

-
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/