From owner-freebsd-current@FreeBSD.ORG Tue Aug 21 09:39:53 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 E8B15106566B; Tue, 21 Aug 2012 09:39:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7F28FC17; Tue, 21 Aug 2012 09:39:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA11195; Tue, 21 Aug 2012 12:39:45 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1T3kw4-000G6A-SJ; Tue, 21 Aug 2012 12:39:44 +0300 Message-ID: <5033575E.1080000@FreeBSD.org> Date: Tue, 21 Aug 2012 12:39:42 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <6882.1345325806@critter.freebsd.dk> <50300C6D.3030501@feral.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Poul-Henning Kamp , Matt Jacob 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 09:39:54 -0000 on 21/08/2012 04:59 Scott Long said the following: > 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. I would like to use this opportunity to remind about another abuse in drivers: MAXBSIZE. This constant should be private to buffer cache / FS drivers layer, but some drivers abuse it for things related to physical I/O (mostly [only?] as bus_dma_tag_create parameter). -- Andriy Gapon