Date: Mon, 6 Jul 2009 02:58:36 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: DFLTPHYS vs MAXPHYS Message-ID: <d763ac660907051158i256c0f93n4a895a992c2a8c34@mail.gmail.com> In-Reply-To: <4A50F619.4020101@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/7/6 Alexander Motin <mav@freebsd.org>: > 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 :) There have been and will be plenty of little embedded CPUs with tiny amounts of cache for quite some time to come. 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. 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. 2c, Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d763ac660907051158i256c0f93n4a895a992c2a8c34>