DFLTPHYS vs MAXPHYS

Alexander Motin mav at FreeBSD.org
Sun Jul 5 19:16:35 UTC 2009


Adrian Chadd wrote:
> 2009/7/6 Alexander Motin <mav at 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 :)

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


More information about the freebsd-arch mailing list