Date: Sun, 4 Jan 2004 17:52:01 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Scott Long <scottl@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: Simple patch: Make DFLTPHYS an option Message-ID: <20040104172940.L22231@gamplex.bde.org> In-Reply-To: <3FF7967A.1090401@freebsd.org> References: <20040103.153644.107852018.imp@bsdimp.com> <3FF7967A.1090401@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 3 Jan 2004, Scott Long wrote: > M. Warner Losh wrote: > > My brother was talking to me about the problems he was having with > > scanners. Turns out that he needed to incrase DFLTYPHYS to 128k to > > make it work. I'd like to make this a simple option, but wanted to > > ask people about it first, for both DFLTPHYS and MAXPHYS. This would > >... > I'm really not comfortable with a patch like this. Changing the default > i/o size is better served as a per-driver tunable/sysctl, like it is in > aac(4). Right, except it's better served by drivers just supporting the maximum i/o size that the hardware can support, without any tunable or sysctl to break and complicate this support. > The key, though, is to ensure that the block system is actually > honoring the per-device disk.d_maxsize variable. I'm not sure if it is > right now. It at least used to work (up to MAXPHYS). The ad driver used a max i/o size of 128K until recently. This has rotted back to 64K for some reason (64K is encoded as DFLTPHYS in the non-dma case and as 64 * 1024 in the dma case). > Also, increasing MAXPHYS will lead to your KVA being chewed up quite > quickly, which in turn will lead to unpleasant panics. A lot of work > needs to go in to fixing this; increasing the value here has little > value even to people who shun seatbelts. Not all that quicky. MAXPHYS affects mainly pbufs, and there are a limited number of them (256 max?), and their kva is statically allocated. 256 times the current MAXPHYS gives 16M. This could easily be increased by a factor of up to about 8 without necesarily breaking things (e.g., by stealing 112MB from buffer kva using VM_BCACHE_SIZE if the default normal-buffer kva size is large (if it is small then there should be space to spare, else there would be no space to spare on systems with more RAM so that the buffer kva size is larger). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040104172940.L22231>