On 11/24/2014 04:35 PM, Christoph Hellwig wrote: > On Mon, Nov 24, 2014 at 04:33:55PM +0100, Hannes Reinecke wrote: >> The megaraid SAS driver uses a shared host tag map internally, >> so we should be telling the block layer about it. > > But it doesn't make use of request->tag yet. This would only be > useful if you got rid of the internal tag allocator. > It is useful as is, as we'll be getting prefixed logging output :-) But yeah, it would be good to get rid of the internal tag allocator. Which I didn't do yet as the driver is using a larger tag map than that one announced to the block layer. This is to facilitate internal command submission, which should always work independent on any tag starvation issues from the upper layers. So when moving to the generic tag allocation code I'd need: - an block-layer helper for allocating a tag without a request (basically separating the existing blk-tag functionality, easy) - introducing 'emergency pools' for the tag map, allowing to allocate a tag even under I/O pressure. What I did was to: - Split off blk_reserve_tag() functionality from blk_start_tag() (and similar with blk_end_tag) - registered the overall size of the shared tag map - called blk_resize_tags() to shrink it to ->can_queue - Implemented a 'force' attribute to blk_reserve_tag() to allow it to dip into the excess size. But then I didn't really like this mis-use of the blk_resize_tag() operation; I'd rather have it marked explicitly. However, I'm sure megasas isn't the only driver requiring such a feature (libata eg would benefit from this, too). Ideas? Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html