Messages in this thread | | | Date | Tue, 27 Mar 2007 14:38:50 -0400 | From | Jeff Garzik <> | Subject | Re: Why is NCQ enabled by default by libata? (2.6.20) |
| |
Mark Rustad wrote: > reorder any queued operations. Of course if you really care about your > data, you don't really want to turn write cache on.
That's a gross exaggeration. FLUSH CACHE and FUA both ensure data integrity as well.
Turning write cache off has always been a performance-killing action on ATA.
> Also the controller used can have unfortunate interactions. For example > the Adaptec SAS controller firmware will never issue more than two > queued commands to a SATA drive (even though the firmware will happily > accept more from the driver), so even if an attached drive is capable of > reordering queued commands, its performance is seriously crippled by not > getting more commands queued up. In addition, some drive firmware seems > to try to bunch up queued command completions which interacts very badly > with a controller that queues up so few commands. In this case turning > NCQ off performs better because the drive knows it can't hold off > completions to reduce interrupt load on the host – a good idea gone > totally wrong when used with the Adaptec controller.
All of that can be fixed with an Adaptec firmware upgrade, so not our problem here, and not a reason to disable NCQ in libata core.
> Today SATA NCQ seems to be an area where few combinations work well. It > seems so bad to me that a whitelist might be better than a blacklist. > That is probably overstating it, but NCQ performance is certainly a big > problem.
Real world testing disagrees with you. NCQ has been enabled for a while now. We would have screaming hordes of users if the majority of configurations were problematic.
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |