From owner-svn-src-all@FreeBSD.ORG Mon Jan 9 22:15:59 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07DB61065679; Mon, 9 Jan 2012 22:15:59 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78C3D8FC14; Mon, 9 Jan 2012 22:15:58 +0000 (UTC) Received: by ghrr16 with SMTP id r16so2060674ghr.13 for ; Mon, 09 Jan 2012 14:15:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZT7FUe3IDs6U2DHnjd6jrcSrnttm42g5DesP9hVcmeM=; b=qQ09OkpbdX02XA7Vl8SBy7uMeUtlew5gjLXvSBceFOUYW1jmgsyyf++Ne3itToa8p/ QrqQVn+Vrb8HmOwFsD4HuPnZzrdA7cfcZzFbPV2M4J83PQUTn6Ynop1MuW/3OmOswMWC 7Tn4S5xq3frafdAGIGgdDqtCHYxcTBmnludFk= MIME-Version: 1.0 Received: by 10.236.91.84 with SMTP id g60mr23607849yhf.90.1326147357696; Mon, 09 Jan 2012 14:15:57 -0800 (PST) Sender: maksim.yevmenkin@gmail.com Received: by 10.101.41.18 with HTTP; Mon, 9 Jan 2012 14:15:57 -0800 (PST) In-Reply-To: <4F0B3C66.6020701@FreeBSD.org> References: <201112282249.pBSMnTZu028304@svn.freebsd.org> <4F0B38B9.1020302@FreeBSD.org> <4F0B3C66.6020701@FreeBSD.org> Date: Mon, 9 Jan 2012 14:15:57 -0800 X-Google-Sender-Auth: -ngbzUl8qu04FNji6cnQyp5Qs-w Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r228939 - head/sys/dev/mps X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 22:15:59 -0000 2012/1/9 Alexander Motin : > On 09.01.2012 21:01, Maksim Yevmenkin wrote: >> >> 2012/1/9 Alexander Motin: >>> >>> On 09.01.2012 20:54, Maksim Yevmenkin wrote: >>>> >>>> >>>> On Wed, Dec 28, 2011 at 2:49 PM, Alexander Motin >>>> =A0wrote: >>>>> >>>>> >>>>> Author: mav >>>>> Date: Wed Dec 28 22:49:28 2011 >>>>> New Revision: 228939 >>>>> URL: http://svn.freebsd.org/changeset/base/228939 >>>>> >>>>> Log: >>>>> =A0Set maximum I/O size for mps(4) to MAXPHYS. Looking into the code,= I >>>>> see >>>>> =A0no reason why it should be limited to 64K of DFLTPHYS. DMA data ta= g is >>>>> any >>>>> =A0way set to allow MAXPHYS, S/G lists (chain elements) are sufficien= t >>>>> and >>>>> =A0overflows are also handled. On my tests even 1MB I/Os are working >>>>> fine. >>>>> >>>>> =A0Reviewed by: =A0ken@ >>>>> >>>>> Modified: >>>>> =A0head/sys/dev/mps/mps_sas.c >>>>> >>>>> Modified: head/sys/dev/mps/mps_sas.c >>>>> >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>> --- head/sys/dev/mps/mps_sas.c =A0Wed Dec 28 22:18:53 2011 >>>>> =A0(r228938) >>>>> +++ head/sys/dev/mps/mps_sas.c =A0Wed Dec 28 22:49:28 2011 >>>>> =A0(r228939) >>>>> @@ -937,6 +937,7 @@ mpssas_action(struct cam_sim *sim, union >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpi->transport_version =3D 0; >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpi->protocol =3D PROTO_SCSI; >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpi->protocol_version =3D SCSI_REV_SPC= ; >>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpi->maxio =3D MAXPHYS; >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpi->ccb_h.status =3D CAM_REQ_CMP; >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; >>>>> =A0 =A0 =A0 =A0} >>>> >>>> >>>> >>>> sorry for the late reply, but can we make in into tunable please? i >>>> have in local tree >>>> >>>> --- mps_sas.c.orig =A0 =A0 =A02011-11-17 02:05:04.000000000 -0800 >>>> +++ mps_sas.c =A0 2011-12-28 16:05:10.000000000 -0800 >>>> @@ -121,6 +121,11 @@ >>>> >>>> =A0MALLOC_DEFINE(M_MPSSAS, "MPSSAS", "MPS SAS memory"); >>>> >>>> +int mps_maxio =3D MAXPHYS; >>>> +TUNABLE_INT("hw.mps.maxio",&mps_maxio); >>>> +SYSCTL_INT(_hw_mps, OID_AUTO, maxio, CTLFLAG_RD,&mps_maxio, 0, >>>> >>>> + =A0 =A0 =A0 "CAM maxio override\n"); >>>> + >>>> =A0static __inline int mpssas_set_lun(uint8_t *lun, u_int ccblun); >>>> =A0static struct mpssas_target * mpssas_alloc_target(struct mpssas_sof= tc >>>> *, >>>> =A0 =A0 =A0struct mpssas_target *); >>>> @@ -938,6 +943,7 @@ >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpi->protocol =3D PROTO_SCSI; >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpi->protocol_version =3D SCSI_REV_SPC; >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpi->ccb_h.status =3D CAM_REQ_CMP; >>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpi->maxio =3D mps_maxio; >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; >>>> =A0 =A0 =A0 =A0} >>>> =A0 =A0 =A0 =A0case XPT_GET_TRAN_SETTINGS: >>> >>> >>> >>> We can. but could you explain why? Have you found any problems this >>> change? >> >> >> not really. i've had this patch in the local tree for a while now. we >> are experimenting with various MAXPHYS/maxio settings and having this >> tunable is very handy. basically, we can set MAXPHYS to some larger >> value and tweak maxio (for testing purposes) without >> recompiling/installing new kernel. > > > I don't really think that it is perfect place for such tunable. It is a b= it > strange IMHO to have different maxio for different types of HBAs except > physical limitations. I would prefer it to be configurable on above layer= s, > for example, file systems, if needed. But if you need it here for somethi= ng, > I won't object against adding it. i'm not sure i understand your point. there certainly drivers that set maxio to value smaller then MAXPHYS. sometimes comments in the code clearly state that this is because of hardware limitation. in case of mps(4) it was not clear at all which values are acceptable for maxio. hence the tunable. > Have you found any benefits of having maxio below MAXPHYS while > experimenting? May be those results could be used to improve FS behavior > somehow to make tuning not needed? we believe so. fs tuning is under investigation as well. thanks max