Re: libata: clustering on or off?

[Jens Axboe <axboe@suse.de>]

On Sun, Aug 28 2005, Jeff Garzik wrote:
> 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.

Well yes, none is not true of course. But it's not a lot, like extra
iterations of the request mappings like it used to. So in by far the
most cases, it should be a win overall.

> >>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...

;-)

-- 
Jens Axboe