From owner-freebsd-arch@FreeBSD.ORG Sun Jul 5 19:16:35 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 79D4D1065674 for ; Sun, 5 Jul 2009 19:16:35 +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 EE6AA8FC1D for ; Sun, 5 Jul 2009 19:16:34 +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 247695245; Sun, 05 Jul 2009 22:16:31 +0300 Message-ID: <4A50FC0B.9090601@FreeBSD.org> Date: Sun, 05 Jul 2009 22:16:27 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Adrian Chadd References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> <20090706005851.L1439@besplex.bde.org> <4A50DEE8.6080406@FreeBSD.org> <20090706034250.C2240@besplex.bde.org> <4A50F619.4020101@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 19:16:35 -0000 Adrian Chadd wrote: > 2009/7/6 Alexander Motin : > >> In this tests you've got almost only negative side of effect, as you have >> said, due to cache misses. Do you really have CPU with so small L2 cache? >> Some kind of P3 or old Celeron? But with 64K MAXPHYS you just didn't get any >> benefit from using bigger block size. > > All the world isn't your current desktop box with only SATA devices :) This is laptop and what do you mean by "only SATA"? You know any storage which performance degrade from big transactions? > There have been and will be plenty of little embedded CPUs with tiny > amounts of cache for quite some time to come. Fine, lets set it to 8K on ARM. What do want to say by that? > You're also doing simple stream IO tests. Please re-think the thought > experiment with a whole lot of parallel IO going on rather than just > straight single stream IO. Please don't. Parallel access with big blocks becomes just more linear with growing block length. For modern drives with >100MB/s speeds and 10ms access time it is just a madness to transfer less then 1MB in one transaction with random access. > Also, please realise that part of having your cache thrashed is what > it does to the performance of -other- code. dd may be fast, but if > you're constantly purging your caches by copying around all of that > data, subsequent code has to go and freshen the cache again. On older > and anaemic embedded/low power boxes the cost of a cache miss vs cache > hit can still be quite expensive. I think that anaemic embedded/low power boxes will prefer to handle operation by chipset hardware as much as possible without interrupting CPU. Also please read one of my previous posts. I don't see why, with, for example, 1M user-level buffer, buffer-cache backed access spited into many small disk transactions could less trash CPU cache. It just transmit same amount of data into the same buffer cachememory addresses. It is not a disk transaction DMA size trashes the cache. If you want to fight it - OK, but not there. -- Alexander Motin