From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 15:52:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 712347F1; Thu, 28 Mar 2013 15:52:34 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 42540C2; Thu, 28 Mar 2013 15:52:33 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r2SFRkju046102; Thu, 28 Mar 2013 09:27:47 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Any objections/comments on axing out old ATA stack? From: Scott Long In-Reply-To: <51536EFD.4060202@freebsd.org> Date: Thu, 28 Mar 2013 09:27:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51536306.5030907@FreeBSD.org> <51536EFD.4060202@freebsd.org> To: mjacob@freebsd.org X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 15:52:34 -0000 On Mar 27, 2013, at 4:13 PM, Matthew Jacob wrote: > On 3/27/2013 2:22 PM, Alexander Motin wrote: >> Hi. >>=20 >> Since FreeBSD 9.0 we are successfully running on the new CAM-based = ATA stack, using only some controller drivers of old ata(4) by having = `options ATA_CAM` enabled in all kernels by default. I have a wish to = drop non-ATA_CAM ata(4) code, unused since that time from the head = branch to allow further ATA code cleanup. >>=20 >> Does any one here still uses legacy ATA stack (kernel explicitly = built without `options ATA_CAM`) for some reason, for example as = workaround for some regression? Does anybody have good ideas why we = should not drop it now? >>=20 > Some people have expressed performance concerns about ATA_CAM. I have = not validated those concerns. Does anyone know of any? The albatross of "CAM is slow" comes up over and over, but I never see = any data to support the claims. So here's an anecdote of my own. Several years ago, Paul Saab and I were looking at performance problems = with the CISS driver. To rule out the "CAM is slow" argument, he wrote = a shim for it that completely cut out CAM and gave it a thin block layer = attachment. The result was that his new driver was actually _slower_ = than the CAM driver. Why? CAM scheduler actually does a really good = job with keeping the pipeline to the driver full and free of stalls. = Also, the code overhead of going through CAM is also much smaller than = people assume, likely because no one actually reads the code before they = make the assumption. Scott