Date: Sat, 14 Nov 2020 10:50:16 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Warner Losh <imp@bsdimp.com> Cc: Scott Long <scottl@samsco.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: MAXPHYS bump for FreeBSD 13 Message-ID: <20201114185016.GM31099@funkthat.com> In-Reply-To: <CANCZdfo23vbCOhMJrekw0GNntcyf54rh8V_jxHKrfjEycrYApw@mail.gmail.com> References: <CANCZdfrG7_F28GfGq05qdA8RG=7X0v%2BHr-dNuJCYX7zgkPDfNQ@mail.gmail.com> <926C3A98-03BF-46FD-9B22-9EFBDC0F44A4@samsco.org> <CANCZdfo23vbCOhMJrekw0GNntcyf54rh8V_jxHKrfjEycrYApw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote this message on Fri, Nov 13, 2020 at 19:16 -0700:
> On Fri, Nov 13, 2020 at 6:23 PM Scott Long <scottl@samsco.org> wrote:
>
> > I have mixed feelings on this. The Netflix workload isn???t typical, and
> > this
> > change represents a fairly substantial increase in memory usage for
> > bufs. It???s also a config tunable, so it???s not like this represents a
> > meaningful
> > diff reduction for Netflix.
> >
>
> This isn't motivated at all by Netflix's work load nor any needs to
> minimize diffs at all. In fact, Netflix had nothing to do with the proposal
> apart from me writing it up.
>
> This is motivated more by the needs of more people to do larger I/Os than
> 128k, though maybe 1MB is too large. Alexander Motin proposed it today
> during the Vendor Summit and I wrote up the idea for arch@.
I ran into this problem recently w/ my work on ggate. I was doing testing
using dd bs=1m. Because of MAXPHYS, the physio for devices breaks down the
request into 128kB segments, which are scheduled serially... This means
that if there is request latency, it is multiplied 8x because of the smaller
requests...
Also, some file systems, like ZFS, ignore the MAXPHYS limit, and pass down
larger IOs anyways, which clearly work well enough that no one complains
about ZFS not working on their devices...
I talked briefly w/ Warner about increasing MAXPHYS not to long ago.
> The upside is that it will likely help benchmarks out of the box. Is that
> > enough of an upside for the downsides of memory pressure on small memory
> > and high iops systems? I???m not convinced. I really would like to see the
> > years of talk about fixing this correctly put into action.
>
> I'd love years of inaction to end too. I'd also like FreeBSD to perform a
> bit better out of the box. Would your calculation have changed had the size
> been 256k or 512k? Both those options use/waste substantially fewer bytes
> per I/O than 1MB.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201114185016.GM31099>