Date: Sun, 21 Mar 2010 22:00:21 -0400 From: jhell <jhell@DataIX.net> To: Alexander Motin <mav@freebsd.org> Cc: FreeBSD-Current <freebsd-current@freebsd.org>, Julian Elischer <julian@elischer.org>, freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS Message-ID: <alpine.BSF.2.00.1003212158190.16103@qvfongpu.qngnvk.ybpny> In-Reply-To: <alpine.BSF.2.00.1003212045540.16103@qvfongpu.qngnvk.ybpny> 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> <4BA62757.7090400@FreeBSD.org> <alpine.BSF.2.00.1003212045540.16103@qvfongpu.qngnvk.ybpny>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > Regards, > > I should have also said that I also repeated the above without setting DFLTPHYS and setting MAXPHYS to 256. Regards, -- jhell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1003212158190.16103>