> On Mar 6, 2016, at 1:27 PM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote: > > On Sun, Mar 06, 2016 at 01:10:42PM -0800, Scott Long wrote: > >> Hi, >> >> The message is harmless, it's a reminder that you should tune the kernel for >> your workload. When the message is triggered, it means that a potential >> command was deferred, likely for only a few microseconds, and then >> everything moved on as normal. >> >> A command uses anywhere from 0 to a few dozen chain frames per I/o, >> depending on the size of the io. The chain frame memory is allocated at >> boot so that it's always available, not allocated on the fly. When I wrote >> this driver, I felt that it would be wasteful to reserve memory for a worst >> case scenario of all large io's by default, so I put in this deferral system >> with a console reminder to for tuning. >> >> Yes, you actually do have 900 io's outstanding. The controller buffers the >> io requests and allows the system to queue up much more than what sata disks >> might allow on their own. It's debatable if this is good or bad, but it's >> tunable as well. >> >> Anyways, the messages should not cause alarm. Either tune up the chain >> frame count, or tune down the max io count. > > I am don't know depends or not, but I see dramaticaly performance drop > at time of this messages. >
Good to know. Part of the performance drop might be because of the slowness of printing to the console. > How I can calculate buffers numbers? If your system is new enough to have mpsutil, please run it ‘mpsutil show iocfacts’. If not, then boot your system with bootverbose and send me the output. > I am have very heavy I/O. Out of curiosity, do you redefine MAXPHYS/DFLTPHYS in your kernel config? > This allocated one for all controllers, or allocated for every controller? It’s per-controller. I’ve thought about making the tuning be dynamic at runtime. I implemented similar dynamic tuning for other drivers, but it seemed overly complex for low benefit. Implementing it for this driver would be possible but require some significant code changes. Scott _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
