From owner-freebsd-arch@FreeBSD.ORG Mon Nov 30 00:41:33 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F3B7106566B; Mon, 30 Nov 2009 00:41:33 +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 C40198FC17; Mon, 30 Nov 2009 00:41:32 +0000 (UTC) Received: from [IPv6:::1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id nAU0eD16057491; Sun, 29 Nov 2009 17:40:13 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Scott Long In-Reply-To: <4B130C6A.70406@elischer.org> Date: Sun, 29 Nov 2009 17:40:12 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <200905191458.50764.jhb@freebsd.org> <200905201522.58501.jhb@freebsd.org> <3bbf2fe10911291429k54b4b7cfw9e40aefeca597307@mail.gmail.com> <66707B0F-D0AB-49DB-802F-13146F488E1A@samsco.org> <4B130C6A.70406@elischer.org> To: Julian Elischer X-Mailer: Apple Mail (2.1076) X-Spam-Status: No, score=-4.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Attilio Rao , arch@freebsd.org Subject: Re: sglist(9) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 00:41:33 -0000 On Nov 29, 2009, at 5:06 PM, Julian Elischer wrote: > Scott Long wrote: > >> I think this is fundamentally wrong. You're proposing exchanging a >> cheap operation of splitting VA's with an expensive operation of >> allocating, splitting, copying, and refcounting sglists. Splitting >> is an excessively common operation, and your proposal will impact >> performance as storage becomes exponentially faster. > > From the perspective of a flashdrive driver the more > efficient the better. The current generation of devices are > doing 800MB/sec (6.4Gb/sec) of scattter-gather random IO > and really that will only go up. We are doing over 130,000 independent > transactions per second and we can put multiple drives in a single > machine. > > These numbers will only increase with future developments. MB/s doesn't tell me much other than the memory bandwidth of the pathways (and that that DMA engines involved don't completely suck). What about transactions/sec? That tells me a lot more about the efficiency of the OS, drivers, and firmware, as well as latency. Scott