Increasing MAXPHYS

[Ivan Voras]

Julian Elischer wrote:
> Alexander Motin wrote:
>> Scott Long wrote:
>>> On Mar 20, 2010, at 11:53 AM, Matthew Dillon wrote:
>>>>    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.
>>> I agree completely.  I did quite a bit of testing on this in 2008 and 
>>> 2009.
>>> I even added some hooks into CAM to support this, and I thought that 
>>> I had
>>> discussed this extensively with Alexander at the time.  Guess it was 
>>> yet another
>>> wasted conversation with him =-(  I'll repeat it here for the record.
> 
> In the Fusion-io driver we find that the limiting factor is not the
> size of MAXPHYS, but the fact that we can not push more than
> 170k tps through geom. (in my test machine. I've seen more on some
> beefier machines), but that is only a limit on small transacrtions,

Do the GEOM threads (g_up, g_down) go into saturation? Effectively all 
IO is serialized through them.