DFLTPHYS vs MAXPHYS

[Alexander Motin]

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