Re: Increasing MAXPHYS

On Sun, 21 Mar 2010 20:54, jhell_at_ wrote:
>
> On Sun, 21 Mar 2010 10:04, mav_at_ wrote:
>> Julian Elischer wrote:
>>> 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,
>>> or in the case of large transfers the DMA engine tops out before a
>>> bigger MAXPHYS would make any difference.
>> 
>> Yes, GEOM is quite CPU-hungry on high request rates due to number of
>> context switches. But impact probably may be reduced from two sides: by
>> reducing overhead per request, or by reducing number of requests. Both
>> ways may give benefits.
>> 
>> If common opinion is not to touch defaults now - OK, agreed. (Note,
>> Scott, I have agreed :)) But returning to the original question, does
>> somebody knows real situation when increased MAXPHYS still causes
>> problems? At least to make it safe.
>> 
>> 
>
> I played with it on one re-compile of a kernel and for the sake of it 
> DFLTPHYS=128 MAXPHYS=256 and found out that I could not cause a crash dump to 
> be performed upon request (reboot -d) due to the boundary being hit for DMA 
> which is 65536. Obviously this would have to be adjusted in ata-dma.c.
>
> I suppose that there would have to be a better way to get the real allowable 
> boundary from the running system instead of setting it statically.
>
> Other then the above I do not see a reason why not... It is HEAD and this is 
> the type of experimental stuff it was meant for.
>
> Regards,
>
>

I should have also said that I also repeated the above without setting 
DFLTPHYS and setting MAXPHYS to 256.

Regards,

-- 

  jhell