Re: libata: clustering on or off?

[Jeff Garzik <jgarzik@pobox.com>]

Jens Axboe wrote:
> On Sun, Aug 28 2005, Arjan van de Ven wrote:
> 
>>On Sun, 2005-08-28 at 05:42 -0400, Jeff Garzik wrote:
>>
>>>The constant ATA_SHT_USE_CLUSTERING in include/linux/libata.h controls
>>>the use of SCSI layer's use_clustering feature, for a great many libata
>>>drivers.
>>>
>>>The current setup has clustering disabled, which in theory causes the
>>>block layer to do less work, at the expense of a greater number of
>>>scatter/gather table entries used.
>>>
>>>Any opinions WRT turning on clustering for libata?
>>
>>in 2.4 clustering was expensive due to a large number of checks that
>>were done (basically the number of fragments got recounted a gazilion
>>times). In 2.6 Jens fixed that afaik to make it basically free...
>>at which point it's a win always.

> Yeah, it wont cost any extra cycles,

A simple grep for QUEUE_FLAG_CLUSTER-related code shows that it -does- 
cost extra cycles.


>>Imo clustering on the driver level should announce driver capabilities.
>>If clustering for some arch/kernel makes it slower, that should be
>>decided at a midlayer level and not in each driver; eg the midlayer
>>would chose to ignore the drivers capabilities.
>>So .. my opinion would be that libata should announce the capability (it
>>seems the code/hw can do it). 
> 
> 
> Agree, we should just remove the ability to control clustering, as it
> really overlaps with the segment settings anyways.

OK, I guess the consensus is to use clustering :)

We'll see if anything blows up in 2.6.14...

	Jeff