Date: Mon, 9 Jan 2012 14:15:57 -0800 From: Maksim Yevmenkin <emax@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r228939 - head/sys/dev/mps Message-ID: <CAFPOs6rNmRKfSK0Y2gM40-B_aCG2F8S0xVKP8R44%2BWk7ULGdmA@mail.gmail.com> In-Reply-To: <4F0B3C66.6020701@FreeBSD.org> References: <201112282249.pBSMnTZu028304@svn.freebsd.org> <CAFPOs6oaMNsHP9VFtL-Szs=vDQj-Ss=JKCECqsUNTMXi7UwNHw@mail.gmail.com> <4F0B38B9.1020302@FreeBSD.org> <CAFPOs6rF1iSDMPdaXCbC_QXsEmqF5iqN3ZNcJkg5AFj15kmGCA@mail.gmail.com> <4F0B3C66.6020701@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2012/1/9 Alexander Motin <mav@freebsd.org>: > On 09.01.2012 21:01, Maksim Yevmenkin wrote: >> >> 2012/1/9 Alexander Motin<mav@freebsd.org>: >>> >>> On 09.01.2012 20:54, Maksim Yevmenkin wrote: >>>> >>>> >>>> On Wed, Dec 28, 2011 at 2:49 PM, Alexander Motin<mav@freebsd.org> >>>> =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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFPOs6rNmRKfSK0Y2gM40-B_aCG2F8S0xVKP8R44%2BWk7ULGdmA>