Thread (6 messages) 6 messages, 4 authors, 2007-03-31

Re: Why is NCQ enabled by default by libata? (2.6.20)

From: Jeff Garzik <hidden>
Date: 2007-03-27 18:38:55
Also in: lkml

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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help