From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 16 00:45:44 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5408DB84; Fri, 16 Aug 2013 00:45:44 +0000 (UTC) (envelope-from prvs=1940958969=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04DCB2350; Fri, 16 Aug 2013 00:45:42 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005518017.msg; Fri, 16 Aug 2013 01:45:40 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 16 Aug 2013 01:45:40 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1940958969=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <86A1FDF5CDCD42DD8CE438576DBB1839@multiplay.co.uk> From: "Steven Hartland" To: "Hans Petter Selasky" , "Alexander Motin" References: <520D4ADB.50209@FreeBSD.org> <520D7479.3060505@bitfrost.no> Subject: Re: New CAM locking preview Date: Fri, 16 Aug 2013 01:45:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Scott Long , Jeff Roberson , ken , freebsd-hackers@FreeBSD.org, FreeBSD SCSI , "Justin T. Gibbs" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 00:45:44 -0000 ----- Original Message ----- From: "Hans Petter Selasky" To: "Alexander Motin" Cc: "Scott Long" ; "Jeff Roberson" ; "ken" ; ; "FreeBSD SCSI" ; "Steven Hartland" ; "Justin T. Gibbs" Sent: Friday, August 16, 2013 1:38 AM Subject: Re: New CAM locking preview > On 08/15/13 23:40, Alexander Motin wrote: >> Hi. >> >> Last weeks I've made substantial progress on my CAM locking work. In >> fact, at this moment I think I've tied all loose ends good enough to >> consider the new design viable and implementation worth further testing >> and bug fixing. So I would like to ask for review of my work from >> everybody who interested in CAM internals. >> >> In short, my idea was to split single per-SIM lock, that creates huge >> congestion under high IOPS, into several smaller ones. So design I've >> finally chosen includes such locks: >> 1) New per-device (per-LUN) locks to protect state of the devices and >> respective periphs. In most cases peripheral drivers just use that lock >> instead of SIM lock used before, so code modification is minimal and >> straightforward. >> 2) New per-target lock to protect list of LUNs fetched from the device. >> 3) Old single per-SIM lock to protect SIM driver internals, but only >> that. No parts of CAM itself use that lock. Keeping it for SIMs allows >> to keep API and hopefully ABI compatibility. Reducing its scope allows >> to reduce congestion. >> 4) New per-SIM lock to protect SIM and device command queues. That >> allows execute queued commands from any context unrelated to other >> locks. Also this lock serializes accesses to sim_action() method for the >> most of commands, this allows to mostly avoid busy spilling on SIM lock >> collision. >> 5) New per-bus locks to protect target, device and periphs reference >> counters. It allows to create and destroy paths unrelated to other locks >> in any possible context. >> > > Sounds very good! I assume you have tested USB mass storage device unplug during various file system operations? It does indeed sound like some very good work, thanks Alexander! @Hans if USB mass storage device unplug is something important to you then might I suggest its a good idea to grab the patches, run your own tests and report any issues you might find as I'm sure this would be most appreciated :) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.