From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 24 20:48:41 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 998AA106566C; Fri, 24 Feb 2012 20:48:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 9EB438FC12; Fri, 24 Feb 2012 20:48:40 +0000 (UTC) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1OIKZeS022862; Sat, 25 Feb 2012 05:20:35 +1100 Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1OIKPkh026371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Feb 2012 05:20:26 +1100 Date: Sat, 25 Feb 2012 05:20:25 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Desai, Kashyap" In-Reply-To: Message-ID: <20120225045730.D2319@besplex.bde.org> References: <20120223094611.GC32748@hoeg.nl> <20120223101157.0bb3f2ee@kan.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , freebsd-stable , "joerg@FreeBSD.org" , "Kenneth D. Merry" , "freebsd-scsi@freebsd.org" , "Justin T. Gibbs" , "McConnell, Stephen" Subject: RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 20:48:41 -0000 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