RE: [PATCH] megaraid_sas: Enable shared host tag map

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Hannes Reinecke [mailto:hare@xxxxxxx]
> Sent: Monday, November 24, 2014 9:21 PM
> To: Christoph Hellwig
> Cc: James Bottomley; Sumit Saxena; Kashyap Desai; linux-
> scsi@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] megaraid_sas: Enable shared host tag map
>
> 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.

Hannes,

I just received your reply... My response crossed with yours. I have
attached preview patch for your reference which I refer in my earlier
response.
Megaraid_sas driver will expose only actual IO command queue depth to the
SML and it will manage all internal used commands without taking any help
from SML.

Driver will now expose max_scsi_cmds to the upper layer which will be
lower than actually FW can support max command.
 E.a
+     instance->max_scsi_cmds = instance->max_fw_cmds -
+                               (MEGASAS_FUSION_INTERNAL_CMDS +
+                               MEGASAS_FUSION_IOCTL_CMDS);

We have to do this to make use of existing OS distribution which really
does not support blk_reserve_tag().

~ Kashyap
>
> 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)

Attachment: blk_shared.patch
Description: Binary data


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux