--- Dave Grothe <[EMAIL PROTECTED]> wrote: > The tradeoff between spin locks and semaphores for queue routine entries is > that with spin locks you are severely restricted as to what you can do with > the kernel, and even more so in 2.6. That's why the semaphore. > > The more recent "lettered" versions of LiS provide for a construct in the > Config file in which you can declare the degree of locking (semaphore) > protection upon entry to put/srv routines. > > qlock driver <driver-name> <value> > > The <value> is as follows: > > 0 = no locking > 1 = lock each q half individually (defaul) > 2 = lock both q halves together > 3 = use a global lock > > Type 1 is the old LiS behavior. Drivers that are written defensively for > SMP environments can probably run with option 0. With no locking at all it > no longer matters whether you do putnext() from interrupt level.
So these options are global for all streams drivers/modules/multiplexors? > Personally, I don't like calling putnext() from interrupt context. When you are trying to deliver something in a timely fashion like a timer indication, it helps to not have all of the overhead and additional delay of having to run the service routine. I wouldn't do it for data although some drivers, most noteably the hme driver on Solaris, do just that. I'll give the lettered versions a try and see if this at least fixes the panic, but in the near term we have to go with the "released" version of LiS. > So I would have coded this construct to fabricate the indication message > and do a putq() into the read queue so as to let the service procedure send > it upstream from guaranteed non-interrupt context. So I take it that a timeout is indeed an "interrupt context". In fact experimentation proves just that. The only way I could get this to work at all was to do just this, put the message on a local private queue in my connection structure and deliver it from the read service routine. I didn't want to use putq() because I don't need all the additional putq() overhead (byte counting and all the rest...) I just need the message delivered and fast... Do you have any additional insights into how to debug these locking problems? I cannot for the life of me actually see deadly embraces with kgdb even when I know I'm in one. thanks- dan _______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
