From owner-freebsd-current@FreeBSD.ORG Tue Aug 21 02:16:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B648106566B; Tue, 21 Aug 2012 02:16:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D23C08FC12; Tue, 21 Aug 2012 02:16:51 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q7L1xgmS050717; Mon, 20 Aug 2012 19:59:42 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Scott Long In-Reply-To: <50300C6D.3030501@feral.com> Date: Mon, 20 Aug 2012 19:59:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6882.1345325806@critter.freebsd.dk> <50300C6D.3030501@feral.com> To: Matt Jacob X-Mailer: Apple Mail (2.1485) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Poul-Henning Kamp , freebsd-current@freebsd.org Subject: Re: BUFSIZ = 1024, still ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 02:16:52 -0000 On Aug 18, 2012, at 3:43 PM, Matthew Jacob wrote: > On 8/18/2012 2:36 PM, Poul-Henning Kamp wrote: >> In message <50300540.9060906@feral.com>, Matthew Jacob writes: >>=20 >>> [...] that there might be a measurable >>> difference for having to copy 4K (unaligned) than 1K (unaligned) to >>> kernel space for disposition. >> Actually, as far as I'm aware, the 4K would be page-aligned by >> default due to our malloc(3) implementation. >>=20 >>> Wasn't there just a recent discussion about running 1.x binaries? >> 1.x binaries wouldn't notice and wouldn't be able to tell >> if BUFSIZ is different in 10.x > I wasn't concerned about those specifically- I was just using this as = an example of leaving stuff alone. >=20 >>> If you're going to talk about making a change to defaults, the = default >>> MAXPHYS and DLFTPHYS have been undersized for years now. >> Indeed, but as I understand it, those require device driver changes ? > Ah, well 10.X would be an ideal time to find out! >=20 This gets brought up from time to time, and I honestly thought that I = swept most of the problems up a few years ago. The mistake that I made = in the mlx driver that was recently corrected was evidence of a previous = sweep. If anyone wants to do another sweep, the thing to grep for is any = drivers that use MAXPHYS to size their i/o's. For the drivers that do = that, you then have to see if they can actually handle an arbitrary = number of scatter-gather elements. If they can't then they need to stop = using MAXPHYS and start using a constant that applies to the driver. My = quick scan shows the following would need to be investigated: sys/dev/ata (legacy ata) /sys/dev/isp /sys/dev/mmcsd /sys/dev/mvs The only other problem is that struct but contains an element sized on = MAXPHYS for doing swapper I/O. Increasing MAXPHYS will increase this, = and at one point I think that Alan Cox might have wanted to find a = better way to hold swap info. Otherwise, increasing MAXPHYS causes no = problems and is something that has run in production for quite some time = at places like Yahoo and Netflix. Scott