Tejun Heo wrote:
Jeff Garzik wrote:
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.
I thought about it but am not really sure whether it's worth the
trouble. We'll be saving on inter-command latency and interrupt
handling which is great but not so sure how noticeable the improvement
would be. NCQ is already all around. How about doing CCC only during
NCQ command phase?
Agreed with all these observations.
In general, the non-NCQ case shares characteristics with host-queue
controllers like sx8. The benefit is nowhere near true command queueing
like NCQ, but the benefits (which you list) are real.
Think of this as a long term requirement. libata _should_ eventually
support this, simply because the gains are there to be had. Several
SATA controllers support queueing of non-NCQ commands.
In the short term, only turning on CCC for NCQ ports makes a lot of sense.
Hmmm... maybe those SSDs would benefit from CCC during non-NCQ commands
though if they don't support NCQ, which they don't really need.
My Gigabyte i-Ram reliably corrupts data within seconds, regardless of
SATA controller :/
Jeff
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
