DFLTPHYS vs MAXPHYS

[Ivan Voras]

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 :)
>
> There have been and will be plenty of little embedded CPUs with tiny
> amounts of cache for quite some time to come.

Yes, and no embedded developer will use the GENERIC kernel on his device
so we can, for this purpose, ignore them :)

> 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, one thing to remember is RAID, both hardware and software. For
example, with gstripe of two drives it's very visible how sharply the
performance falls if you go from 32 kB stripes to 64 kB stripes, since
the upper layer passes 64 kB requests to GEOM. GEOM will pass the
request to gstripe, which will in the first case request 32 kB from each
drive (faster) and in the second case only 64 kB from one of the drives
(no performance gain from striping).

(please adjust for 32/64 -> 64/128 if appropriate, I don't have the raw
numbers now)

Of course it's not a reason as-is but both Windows and Linux have 1 MB
BIO buffers so it's reasonable to assume that vendors will optimize for
that size if they can.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090709/11306165/signature.pgp