From owner-freebsd-current@freebsd.org Sun Jun 4 03:55:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD441AF9DB8 for ; Sun, 4 Jun 2017 03:55:58 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F5353BFF for ; Sun, 4 Jun 2017 03:55:58 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 1AAFE13704 for ; Sun, 4 Jun 2017 03:55:55 +0000 (UTC) Subject: Re: Time to increase MAXPHYS? To: freebsd-current@freebsd.org References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> From: Allan Jude Message-ID: <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> Date: Sat, 3 Jun 2017 23:55:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Cx0stUMhFrq7XmDAEA141WXqMt1Densin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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: Sun, 04 Jun 2017 03:55:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Cx0stUMhFrq7XmDAEA141WXqMt1Densin Content-Type: multipart/mixed; boundary="v8v1cFKcV5SNXqoRsNBIFD65mdBoUKUi4"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> Subject: Re: Time to increase MAXPHYS? References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> In-Reply-To: <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> --v8v1cFKcV5SNXqoRsNBIFD65mdBoUKUi4 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2017-06-03 22:35, Julian Elischer wrote: > On 4/6/17 4:59 am, Colin Percival wrote: >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson= @ >> wrote: >>> Add better support for larger I/O clusters, including larger physical= >>> I/O. The support is not mature yet, and some of the underlying >>> implementation >>> needs help. However, support does exist for IDE devices now. >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it= >> again, >> or do we need to wait at least two decades between changes? >> >> This is hurting performance on some systems; in particular, EC2 "io1" >> disks >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized >> spinning rust) >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) >> recommends >> using a maximum I/O size of 1 MB (and despite NFS not being *physical*= >> I/O it >> seems to still be limited by MAXPHYS). >> > We increase it in freebsd 8 and 10.3 on our systems, Only good results= =2E >=20 > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O > transfer size */ >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" At some point Warner and I discussed how hard it might be to make this a boot time tunable, so that big amd64 machines can have a larger value without causing problems for smaller machines. ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some of the benefit. I am preparing some benchmarks and other data along with a patch to increase the maximum size of pipe I/O's as well, because using 1MB offers a relatively large performance gain there as well. --=20 Allan Jude --v8v1cFKcV5SNXqoRsNBIFD65mdBoUKUi4-- --Cx0stUMhFrq7XmDAEA141WXqMt1Densin Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJZM4TKAAoJEBmVNT4SmAt++RsQAMESHM5nn7rA7FXik+B1c7b7 RIuGsZmvOwMJ+ByTnW+i5jd/oVEQMl488Jq0mrzNUcTNwesJzBHyLfZUk4tsCW2E nmj6o9E4t/EQJ+v/LwCVAxtdFuGDCFH4gQGeoH31XqXWA2qguAHdm8hCLE3lw7yv xnVUKIsH+B1XYrYtnugK4QQtiKuxvQg1m0iJGR8jQoRr1qqz41yBxc3ZsBIvRSsh 6lw6PHOQLMaxp8vLiMumFcCB4ubMaWuSA0xvzKjWfeFqqNIqH6yut5va9TVZLdHq yNlZz+Cu8ZBxnt+A+ndZtkaC0CvuTyrh9wkgGbF9wfuD83+Td5/LwIYbfqpNASGE 3dpNOIgiz/bpp+s7g9uqEiKnP1BWN7BEgouj/rJ74y1ItsVRljKr+ss4Mmxw12Rc 9J02M8aCYN1uTKDbLoT30FON8kbxzQliXZj6Co/CK1Lv6ngv9UBJKzfxeJ22j3Xz R014WqSfjQxmBCtXZBtYh5CLAmBtWV+9WD/RP4/8Ub0mcRhCgUvRlTE8EJ9b14ZW Scns5WEkFMV4kfNkW9vGmwAid6YM+Ka5xns7f4+88feXdd816Qq4lbkhkaCj76+i cUoCQMaCxZ2s8/IQkjilJZX+tNvKTlMbbr22n1ka05sLE+ajqE7SBXpX0AbIGW3P 02d/gYD1bQ59mDSDd54M =eW2j -----END PGP SIGNATURE----- --Cx0stUMhFrq7XmDAEA141WXqMt1Densin--