Messages in this thread | | | Date | Tue, 22 Sep 1998 21:01:34 +1000 | From | Richard Gooch <> | Subject | Re: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...) |
| |
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/
| |