Date: Sat, 3 Jun 2017 23:33:02 -0600 From: Warner Losh <imp@bsdimp.com> To: Colin Percival <cperciva@tarsnap.com> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: Time to increase MAXPHYS? Message-ID: <CANCZdfrUMn3XXJHY2jpQBcWqokeqpZFQnVWJHpcOaej7NsbNjQ@mail.gmail.com> In-Reply-To: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 3, 2017 at 2:59 PM, Colin Percival <cperciva@tarsnap.com> 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). > MAXPHYS is the largest I/O transaction you can push through the system. It doesn't matter that the I/O is physical or not. The name is a relic from a time that NFS didn't exist. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrUMn3XXJHY2jpQBcWqokeqpZFQnVWJHpcOaej7NsbNjQ>