Elias Oltmanns <eo@xxxxxxxxxxxxxx> wrote: > Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx> wrote: >> On Monday 24 November 2008, Elias Oltmanns wrote: [...] >>> Finally, some more general blathering on the topic at hand: A while ago, >>> I spent some thought on the possibilities of giving the block layer a >>> notion of linked device queues as an equivalent hwgroups in ide, >>> scsi_hosts or ata_ports and let it take care of time / bandwidth >>> distribution among the queues belonging to one group. This is, as I >>> understand, pretty much what your code is relying on since you have >>> chucked out choose_drive(). However, this turned out not to be too easy >> >> This is the right way to go and I has always advocated for it. However >> after seeing how libata got away with ignoring the issue altogether >> I'm no longer sure of this. I haven't seen any bug reports which would >> indicate that simplified approach has any really negative consequences. > > Well, libata can safely ignore it since scsi takes care of that (see > scsi_run_queue() which is called on command completion). > >> >> [ Still would be great to have the control over bandwitch of "queue-group" >> at the block layer level since we could also use it for distributing the >> available PCI[-E] bus bandwitch. ] >> >>> and I'm not quite sure whether we really want to go down that road. One >>> major problem is that there is no straight forward way for the block >>> layer to know, whether a ->request_fn() has actually taken a request off >>> the queue and if not (or less than queue_depth anyway), whether it's >>> just the device that couldn't take any more or the controller instead. >>> On the whole, it seems not exactly trivial to get it right and it would >>> probably be a good idea to consult Jens and perhaps James before >> >> I think that having more information returned by ->request_fn() could be >> beneficial to the block layer (independently whether we end up adding >> support for "queue-groups" to the block layer or not) but this definitely >> needs to be verified with Jens & James. > > Some time back, I raised this with Jens in connection with your previous > version of the patchset [1]. I didn't get an answer at the time but > perhaps it would help to raise it again in its own right and to give > some more examples of its potential merits. [1] http://marc.info/?l=linux-ide&m=122470007616121&w=2 What ever does it mean that I missed something vital in this email too? ;-) Regards, Elias -- To unsubscribe from this list: 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
