Date: Sun, 04 Jan 2004 00:15:21 -0700 From: Scott Long <scottl@freebsd.org> To: Bruce Evans <bde@zeta.org.au> Cc: arch@freebsd.org Subject: Re: Simple patch: Make DFLTPHYS an option Message-ID: <3FF7BD89.4080406@freebsd.org> In-Reply-To: <20040104172940.L22231@gamplex.bde.org> References: <20040103.153644.107852018.imp@bsdimp.com> <3FF7967A.1090401@freebsd.org> <20040104172940.L22231@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > 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. > aac(4) is an example of hardware where the limits are somewhat flexible if you know what you are doing. The driver cannot make the more aggressive choice on its own. > >>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). > I've seen evidence lately that this might be broken, but I need to track it down further. > >>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). > VFS, softupdates, UFS_DIRHASH, etc, all contribute to KVA being eaten faster than it used to be. Even with smarter tuning of common culprits like maxvnodes, KVA is still under a lot of pressure. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FF7BD89.4080406>