Re: Time to increase MAXPHYS?

On Sun, Jun 4, 2017 at 1:33 PM, Warner Losh <imp_at_bsdimp.com> wrote:

> On Sat, Jun 3, 2017 at 2:59 PM, Colin Percival <cperciva_at_tarsnap.com>
> 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).
> >
>
> 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.
>


Sounds like MAXPHYS usage has grown too widespread than intended to be.

Would it be better for specific components to depart from MAXPHYS if they
care about performance, and use more specific limit from protocol or
hardware spec etc. e.g. MAXDMASIZE, MAX_ATA_IO_SIZE, and maybe some query
functions.

Having a global max for everything to use just doesn't feel right.

If this is the direction to go in the long run, then changing MAXPHYS
references to own-defined limitations may be more meaningful than raising
it universally. Then I'd propose not to raise it, or people would not be
motivated to fix that.

A quick grep shows that many references use it as a cap only 'for safety'.


-Jia-Shiun