Re: [RFC] AHCI Command Completion Coalescing(CCC) proposal

[Jeff Garzik <jgarzik@pobox.com>]

zhao, forrest wrote:
> On Thu, 2006-06-08 at 11:01 -0400, Jeff Garzik wrote: 
>>> >From my understanding, the measurement of "IRQ numbers per second"
>>> should be based on per-port instead of all ports of a SATA controller.
>> No, it should be all ports of a SATA controller.
> 
> Maybe I didn't state my ideas clearly. Let me explain it by an example.
> 
> 1 Assume there are 2 active ports(P0 and P1) on a system, they all run
> under non-NCQ mode
> 2 During a certain period, P0 is heavily loaded, which generates >1000
> interrupts per second; P1 is idle, which generates no interrupt
> 3
> 3.1 If the measurement of "IRQ numbers per second" is based on all
> active ports of a SATA controller, CCC is activated by CCC_PORTS being
> set to 0x3, CCC_CTL.CC being set to 64(32*2). Then the problem comes:
> the CCC interrupt will be raised only when the timeout expires, this is
> because P1 is in idle, thus hCccComplete can never be greater than or
> equal to 64, the maximum of hCccComplete is 32.
> 3.2 If the measurement of "IRQ numbers per second" is based on per-port,
> we can know that P0 is heavily-loaded, then CCC is activated by
> CCC_PORTS being set to 0x1, CCC_CTL.CC being set to 32. Then CCC can
> take effect as we have expected :)
> NOTE: hCccComplete is the term used in section 11 of AHCI spec1.1

I'm still not sure I follow you?

When AHCI runs out of commands to execute, it transitions from H:Idle to 
Ccc:SetIS.

IMPORTANT NOTE:  In order for CCC to be effective on AHCI, ahci.c and 
libata (and sata_sil24) must be updated to support queuing a list of 
non-NCQ commands onto the controller, and recovering from errors in the 
case where a command list full of non-NCQ commands is present.

Also, you should scale up CCC_CTL.CC really based on "commands in 
flight" across all ports.

	Jeff