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

Richard Gooch (rgooch@atnf.csiro.au)
Tue, 22 Sep 1998 23:54:29 +1000


Alan Cox writes:
> > But if your interrupt handler doesn't register/mark a BH, then the
> > costs of "BH processing" (i.e. (bh_active & bh_mask)) are
> > trivial. Where is the gain in that extra flag?
>
> Probably small. However
>
> 1. It also does signal processing and rescheduling on the return path
> (the latter is now a lot cheaper with current->need_resched on smp)

That's a separate issue from BH processing, though.

> 2. You often have woken a task but dont want it to leap into life
> instantly

I've recently looked at this, and if you wake an RT process then
current->need_resched is set to 1 anyway. Same story if the woken
process has a higher dynamic priority than current.
So in fact you can't avoid the context switch anyway.

> > >From looking at the current Linux capabilities, it looks to me like we
> > can indeed give hard-RT performance. Sure, it may mean not using
> > broken 8390 drivers which globally disable interrupts while spending
> > 1.6 ms reading a packet, but hey, we can live with that ;-)
>
> I've been working on two things where hard real time is an important
> matter. That is localtalk cards and dumb synchronous cards. The former
> requires I hit 90uS or so worst case latency on receive, the latter to
> do 2Mbits is even tighter.
>
> > Being able to do all this with normal Linux without having to resort
> > to RTLinux is a goal worthy of pursuit.
>
> No argument ;)

:-)

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/