From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 15:14:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9C7A106566B; Mon, 17 Sep 2012 15:14:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1968FC0A; Mon, 17 Sep 2012 15:14:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D0E85B91A; Mon, 17 Sep 2012 11:13:59 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 17 Sep 2012 08:25:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <6A0C3360-0A1E-4905-A33E-D6CC590D7A5A@bnc.net> <50524694.3040808@gmail.com> In-Reply-To: <50524694.3040808@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209170825.24812.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 17 Sep 2012 11:13:59 -0400 (EDT) Cc: matt , Garrett Cooper , Andrey Zonov , Achim Patzner Subject: Re: mfi driver performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 17 Sep 2012 15:14:00 -0000 On Thursday, September 13, 2012 4:48:20 pm matt wrote: > On 09/13/12 13:13, Garrett Cooper wrote: > > On Thu, Sep 13, 2012 at 12:54 PM, matt wrote: > >> On 09/10/12 19:31, Garrett Cooper wrote: > > ... > > > >> It seems hw.mfi.max_cmds is read only. The performance is pretty close to > >> expected with no nvram or bbu on this card and commodity disks from 1.5 > >> years ago, as far as I'm concerned. I'd love better write performance, but > >> it's probably being held back by the single platter in the mirror when it is > >> writing far from its edge. > > Try loader.conf: > > > > $ grep -r hw.mfi.max_cmds /sys/dev/mfi/ > > /sys/dev/mfi/mfi.c:TUNABLE_INT("hw.mfi.max_cmds", &mfi_max_cmds); > > > > Cheers, > > -Garrett > $ cat /usr/src/sys/dev/mfi/*.c | fgrep 'max_cmds' > static int mfi_max_cmds = 128; > TUNABLE_INT("hw.mfi.max_cmds", &mfi_max_cmds); > SYSCTL_INT(_hw_mfi, OID_AUTO, max_cmds, CTLFLAG_RD, &mfi_max_cmds, > ncmds = MIN(mfi_max_cmds, sc->mfi_max_fw_cmds); > > Definitely a loader tunable, thanks. I'll try increasing and decreasing > the value and running bonnie again...Still not sure whether I'm getting > 3gb/s and 6gb/s negotiation with my drives. MPS correctly reported da > devices with 600mb/s and 300mb/s transfers where appropriate. mfiutil > doesn't seem to know, and mfip devices appear as 150mb/s. No transfer > speed message when mfisyspd devices attach. Mess with mfi_max_cmds at your own risk. The limit was added to work around broken mfi(4) firmware revisions that would lock up when the entire command queue (256) was used. Just a suggestion to be cautious. It is probably safe to use more than 128, but I would be wary of using all of the slots on your adapter. (A verbose boost will show you the number of command slots your firmware supports.) -- John Baldwin