From owner-svn-src-all@FreeBSD.ORG Mon Jan 9 19:13:54 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 0658E1065677; Mon, 9 Jan 2012 19:13:54 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 144D78FC13; Mon, 9 Jan 2012 19:13:52 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so4420306wib.13 for ; Mon, 09 Jan 2012 11:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Vh+6PAA88msTN5306MLyq91AVq3T61rqDVFdGE1lk5s=; b=dmSgwI1u3kLqhK2B1CMZXZ+3pW9QwR/8e9z+KGRZU6GuxI7Hjk8CaudkBl1Aa29TGq krIAghZeAzg2X0H4zbTshROGHAdR3h6YFCg/tH5hUVPRwdjfpiNoYvtnpDqCS65QbNUY 8VGEIHfScsMaEvsLZMJNLxlCDXq/ur+Ya5xCI= Received: by 10.180.83.69 with SMTP id o5mr30579362wiy.1.1326136432113; Mon, 09 Jan 2012 11:13:52 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id 28sm80358017wby.3.2012.01.09.11.13.50 (version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 11:13:51 -0800 (PST) Sender: Alexander Motin Message-ID: <4F0B3C66.6020701@FreeBSD.org> Date: Mon, 09 Jan 2012 21:13:42 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Maksim Yevmenkin References: <201112282249.pBSMnTZu028304@svn.freebsd.org> <4F0B38B9.1020302@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit 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 19:13:54 -0000 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 wrote: >>>> >>>> Author: mav >>>> Date: Wed Dec 28 22:49:28 2011 >>>> New Revision: 228939 >>>> URL: http://svn.freebsd.org/changeset/base/228939 >>>> >>>> Log: >>>> Set maximum I/O size for mps(4) to MAXPHYS. Looking into the code, I see >>>> no reason why it should be limited to 64K of DFLTPHYS. DMA data tag is >>>> any >>>> way set to allow MAXPHYS, S/G lists (chain elements) are sufficient and >>>> overflows are also handled. On my tests even 1MB I/Os are working fine. >>>> >>>> Reviewed by: ken@ >>>> >>>> Modified: >>>> head/sys/dev/mps/mps_sas.c >>>> >>>> Modified: head/sys/dev/mps/mps_sas.c >>>> >>>> ============================================================================== >>>> --- head/sys/dev/mps/mps_sas.c Wed Dec 28 22:18:53 2011 (r228938) >>>> +++ head/sys/dev/mps/mps_sas.c Wed Dec 28 22:49:28 2011 (r228939) >>>> @@ -937,6 +937,7 @@ mpssas_action(struct cam_sim *sim, union >>>> cpi->transport_version = 0; >>>> cpi->protocol = PROTO_SCSI; >>>> cpi->protocol_version = SCSI_REV_SPC; >>>> + cpi->maxio = MAXPHYS; >>>> cpi->ccb_h.status = CAM_REQ_CMP; >>>> break; >>>> } >>> >>> >>> sorry for the late reply, but can we make in into tunable please? i >>> have in local tree >>> >>> --- mps_sas.c.orig 2011-11-17 02:05:04.000000000 -0800 >>> +++ mps_sas.c 2011-12-28 16:05:10.000000000 -0800 >>> @@ -121,6 +121,11 @@ >>> >>> MALLOC_DEFINE(M_MPSSAS, "MPSSAS", "MPS SAS memory"); >>> >>> +int mps_maxio = MAXPHYS; >>> +TUNABLE_INT("hw.mps.maxio",&mps_maxio); >>> +SYSCTL_INT(_hw_mps, OID_AUTO, maxio, CTLFLAG_RD,&mps_maxio, 0, >>> >>> + "CAM maxio override\n"); >>> + >>> static __inline int mpssas_set_lun(uint8_t *lun, u_int ccblun); >>> static struct mpssas_target * mpssas_alloc_target(struct mpssas_softc *, >>> struct mpssas_target *); >>> @@ -938,6 +943,7 @@ >>> cpi->protocol = PROTO_SCSI; >>> cpi->protocol_version = SCSI_REV_SPC; >>> cpi->ccb_h.status = CAM_REQ_CMP; >>> + cpi->maxio = mps_maxio; >>> break; >>> } >>> case 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 bit strange IMHO to have different maxio for different types of HBAs except physical limitations. I would prefer it to be configurable on above layers, for example, file systems, if needed. But if you need it here for something, I won't object against adding it. 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? -- Alexander Motin