Date: Sat, 25 Feb 2012 05:20:25 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: "Desai, Kashyap" <Kashyap.Desai@lsi.com> Cc: Ed Schouten <ed@80386.nl>, freebsd-stable <freebsd-stable@freebsd.org>, "joerg@FreeBSD.org" <joerg@freebsd.org>, "Kenneth D. Merry" <ken@freebsd.org>, "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, "Justin T. Gibbs" <gibbs@freebsd.org>, "McConnell, Stephen" <Stephen.McConnell@lsi.com> Subject: RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Message-ID: <20120225045730.D2319@besplex.bde.org> In-Reply-To: <B2FD678A64EAAD45B089B123FDFC3ED72B96D3495D@inbmail01.lsi.com> References: <B2FD678A64EAAD45B089B123FDFC3ED72B96D3484A@inbmail01.lsi.com> <20120223094611.GC32748@hoeg.nl> <B2FD678A64EAAD45B089B123FDFC3ED72B96D34929@inbmail01.lsi.com> <20120223101157.0bb3f2ee@kan.dyndns.org> <B2FD678A64EAAD45B089B123FDFC3ED72B96D3495D@inbmail01.lsi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 Feb 2012, Desai, Kashyap wrote: >> From: Alexander Kabaev [mailto:kabaev@gmail.com] >> ... >> sleep locks are by definition unbound. There is no spinning, no priority >> propagation. Holders are free to take, say, page faults and go to long >> journey to disk and back, etc. > > I understood your above lines. >> Hardly the stuff _anyone_ would want to >> do from interrupt handler, thread or otherwise. > > So the way mps driver does in interrupt handler is as below. > > mps_lock(sc); > mps_intr_locked(data); > mps_unlock(sc); > > We hold the mtx lock in Interrupt handler and do whole bunch of work(this is bit lengthy work) under that. > It looks mps driver is miss using mtx_lock. Are we ? No. Most NIC drivers do this. Lengthy work isn't as long as it used to be, and here the lock only locks out other accesses to a single piece of hardware (provided sc is for a single piece of hardware as it should be). Worry instead about more global locks, either in your driver or in upper layers. You might need one to lock your whole driver, and upper layers might need one to lock things globally too. Giant locking is an example of the latter. I don't trust the upper layers much, but for interrupt handling they can be trusted to not have anything locked when the interrupt handler is called (except for Giant locking when the driver requests this). Also worry about your interrupt handler taking too long -- although nothing except interrupt thread priority prevents other code running, it is possible that other code doesn't get enough (or any) cycles if an interrupt handler is too hoggish. This problem is smaller than when there was a single ~1 MHz CPU doing PIO. With multiple ~2GHz CPUs doing DMA, the interrupt handler can often be 100 times sloppier without anyone noticing. But not 1000 times, and not 100 times with certain hardware. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120225045730.D2319>