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.
Regards,
--
jhell
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
