Re: Time to increase MAXPHYS?

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_at_
>> 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.
> 
> sys/sys/param.h:#define MAXPHYS         (1024 * 1024)   /* max raw I/O
> transfer size */
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

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.

-- 
Allan Jude