jhell at DataIX.net
Mon Mar 22 02:00:03 UTC 2010
On Sun, 21 Mar 2010 20:54, jhell@ wrote:
> On Sun, 21 Mar 2010 10:04, mav@ 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.
I should have also said that I also repeated the above without setting
DFLTPHYS and setting MAXPHYS to 256.
More information about the freebsd-current