From owner-freebsd-scsi@FreeBSD.ORG Fri Mar 25 12:49:36 2011 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 6770D1065670 for ; Fri, 25 Mar 2011 12:49:36 +0000 (UTC) (envelope-from nschelly@dyn.com) Received: from dynmail-01-mht.dyndns.com (dynmail-01-mht.dyndns.com [216.146.45.13]) by mx1.freebsd.org (Postfix) with ESMTP id AE0D58FC17 for ; Fri, 25 Mar 2011 12:49:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dynmail-01-mht.dyndns.com (Postfix) with ESMTP id 09F5F17CE004; Fri, 25 Mar 2011 08:49:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at dynmail-01-mht.dyndns.com Received: from dynmail-01-mht.dyndns.com ([127.0.0.1]) by localhost (dynmail-01-mht.dyndns.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFcayHg4ReZv; Fri, 25 Mar 2011 08:49:34 -0400 (EDT) Received: from mail.corp.dyndns.com (mail.corp.dyndns.com [216.146.45.14]) by dynmail-01-mht.dyndns.com (Postfix) with ESMTP id B29AD23404D; Fri, 25 Mar 2011 08:49:34 -0400 (EDT) Date: Fri, 25 Mar 2011 08:49:34 -0400 (EDT) From: Neil Schelly To: Erich Weiler Message-ID: <8606490.140484.1301057374592.JavaMail.root@mail.corp> In-Reply-To: <4D8A1EDB.50206@soe.ucsc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.12.87] X-Mailer: Zimbra 6.0.7_GA_2473.UBUNTU8 (ZimbraWebClient - SAF3 (Linux)/6.0.7_GA_2473.UBUNTU8) Cc: freebsd-scsi@freebsd.org Subject: Re: Serious Dell Sadness - H200, H700, and H800 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, 25 Mar 2011 12:49:36 -0000 > Neil, you mentioned that there may be a performance hit from the extra > read operation the patch executes. Does that mean for every single > read > or write operation, there is an extra read operation? Such that the > number of I/Os to the disk is multiplied by two? Or is it only an > extra > read operation at the end of an interrupt or something (forgive my > ignorance, I'm not fully versed on how interrupts affect the bus)? If > the latter, would the performance hit only be like 1-2% in practice? > If > the former, would that mean a 50% performance hit? Scott's off the cuff estimate of the performance hit was 1-5%. Here's his description of what the patch actually accomplishes. > What my patch does is to re-flush the bus at the end of the interrupt > handler and check for any new command completions that have happened > while the handler was running. This isn't a perfect solution, > unfortunately. First, it adds cost through extra PCI bus reads needed > for the flush. Second, and most importantly, it doesn't completely > close the race; even after the recheck is complete, an > interrupt+completion could be transmitted from the controller in > between the driver doing that re-check and then returning to the OS. > So a race could still exist, albeit a lot smaller than it was when no > recheck was done. The only real way to close the race is to have > interrupt latching work properly so that interrupts don't get lost. Ultimately, it appears that the PCI emulation of the controller firmwares doesn't quite handle the interrupt latching properly, causing lost interrupts. I suspect most other (other OS) implementations of this driver are using MSI to request PCI Express semantics, and that the firmware has been more thoroughly tested using the edge-triggered interrupts there. While I wouldn't doubt that this patch could go into the driver code and make it a better driver, it's worth mentioning that the "right" way to fix it may be to switch to using the more robust and better performing PCI Express semantics. -- Neil Schelly Director of Uptime Dynamic Network Services, Inc. W: 603-296-1581 M: 508-410-4776 http://www.dyndns.com