Date: Sat, 20 Mar 2010 10:53:17 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alexander Motin <mav@freebsd.org> Cc: FreeBSD-Current <freebsd-current@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS Message-ID: <201003201753.o2KHrH5x003946@apollo.backplane.com> References: <4BA4E7A9.3070502@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:All above I have successfully tested last months with MAXPHYS of 1MB on
:i386 and amd64 platforms.
:
:So my questions are:
:- does somebody know any issues denying increasing MAXPHYS in HEAD?
:- are there any specific opinions about value? 512K, 1MB, MD?
:
:--
:Alexander Motin
(nswbuf * MAXPHYS) of KVM is reserved for pbufs, so on i386 you
might hit up against KVM exhaustion issues in unrelated subsystems.
nswbuf typically maxes out at around 256. For i386 1MB is probably
too large (256M of reserved KVM is a lot for i386). On amd64 there
shouldn't be a problem.
Diminishing returns get hit pretty quickly with larger MAXPHYS values.
As long as the I/O can be pipelined the reduced transaction rate
becomes less interesting when the transaction rate is less than a
certain level. Off the cuff I'd say 2000 tps is a good basis for
considering whether it is an issue or not. 256K is actually quite
a reasonable value. Even 128K is reasonable.
Nearly all the issues I've come up against in the last few years have
been related more to pipeline algorithms breaking down and less with
I/O size. The cluster_read() code is especially vulnerable to
algorithmic breakdowns when fast media (such as a SSD) is involved.
e.g. I/Os queued from the previous cluster op can create stall
conditions in subsequent cluster ops before they can issue new I/Os
to keep the pipeline hot.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003201753.o2KHrH5x003946>