Date: Sun, 21 Mar 2010 16:04:07 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: Scott Long <scottl@samsco.org>, FreeBSD-Current <freebsd-current@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS Message-ID: <4BA62757.7090400@FreeBSD.org> In-Reply-To: <4BA532FF.6040407@elischer.org> References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <4BA532FF.6040407@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BA62757.7090400>