From owner-freebsd-arch@FreeBSD.ORG Sat Jan 3 23:17:05 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4A4216A4CE for ; Sat, 3 Jan 2004 23:17:05 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 0BC9643D58 for ; Sat, 3 Jan 2004 23:17:04 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 2383 invoked by uid 1002); 4 Jan 2004 07:17:01 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 4 Jan 2004 07:17:01 -0000 Message-ID: <3FF7BD89.4080406@freebsd.org> Date: Sun, 04 Jan 2004 00:15:21 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031103 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <20040103.153644.107852018.imp@bsdimp.com> <3FF7967A.1090401@freebsd.org> <20040104172940.L22231@gamplex.bde.org> In-Reply-To: <20040104172940.L22231@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Simple patch: Make DFLTPHYS an option X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2004 07:17:05 -0000 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