From owner-freebsd-arch@FreeBSD.ORG Sun Jul 5 14:37:21 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B12011065670 for ; Sun, 5 Jul 2009 14:37:21 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 335458FC17 for ; Sun, 5 Jul 2009 14:37:20 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247686623; Sun, 05 Jul 2009 17:37:17 +0300 Message-ID: <4A50BA9A.9080005@FreeBSD.org> Date: Sun, 05 Jul 2009 17:37:14 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Bruce Evans References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> In-Reply-To: <20090705223126.I42918@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gary.jennejohn@freenet.de, freebsd-arch@FreeBSD.org Subject: Re: DFLTPHYS vs MAXPHYS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 14:37:21 -0000 Bruce Evans wrote: > On Sun, 5 Jul 2009, Alexander Motin wrote: >>>> Isn't it a time to review their values for increasing? 64KB looks >>>> funny, comparing to modern memory sizes and data rates. It just >>>> increases interrupt rates, but I don't think it really need to be so >>>> small to improve interactivity now. > > 64K is large enough to bust modern L1 caches and old L2 caches. Make the > size bigger to bust modern L2 caches too. Interrupt rates don't matter > when you are transfering 64K items per interrupt. How cache size related to it, if DMA transfers data directly to RAM? Sure, CPU will invalidate related cache lines, but why it should invalidate everything? Small transfers give more work to all levels from GEOM down to CAM/ATA, controllers and drives. It is not just a context switching. >>> I wonder whether all drivers can correctly handle larger values for >>> DFLTPHYS. > > Most can't, since their hardware can't. They can fake it (ata used to) > but there is negative point in this for most drivers, since geom already > reblocks for disk devices and reblocking would be wrong for devices like > tapes. I am not speaking about reblocking. I am speaking about best possible hardware usage. I can't say about the most, but at least AHCI and modern SiI SATA chips, I have worked closely, practically have no limits for transaction size, except the amount of memory their drivers allocate for S/G table. My new drivers are able to self-tune for any MAXPHYS value. -- Alexander Motin