Increasing MAXPHYS

Ivan Voras ivoras at freebsd.org
Sat Mar 20 21:50:12 UTC 2010


Julian Elischer wrote:
> Ivan Voras wrote:
>> 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.
> 
> basically..
> 
> You can get better throughput by using TSC for timing because the geom 
> and devstat code does a bit of timing.. Geom can be told to turn off
> it's timing but devstat can't. The 170 ktps is with TSC as timer,
> and geom timing turned off.

I see. I just ran randomio on a gzero device and with 10 userland 
threads (this is a slow 2xquad machine) I get g_up and g_down saturated 
fast with ~~ 120 ktps. Randomio uses gettimeofday() for measurements.

Hmm, it looks like it could be easy to spawn more g_* threads (and, 
barring specific class behaviour, it has a fair chance of working out of 
the box) but the incoming queue will need to also be broken up for 
greater effect.



More information about the freebsd-arch mailing list