Re: Increasing MAXPHYS

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,

-- 

  jhell