: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>
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"