From: Hans de Goede <hdegoede@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Gerd Hoffmann <kraxel@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-usb@vger.kernel.org, linux-scsi@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] uas: Limit qdepth at the scsi-host level
Date: Sun, 20 Mar 2016 14:28:26 +0100 [thread overview]
Message-ID: <56EEA57A.9050107@redhat.com> (raw)
In-Reply-To: <1458407176.2288.5.camel@HansenPartnership.com>
Hi,
On 19-03-16 18:06, James Bottomley wrote:
> On Sat, 2016-03-19 at 09:59 +0100, Hans de Goede wrote:
>> Commit 64d513ac31bd ("scsi: use host wide tags by default") causes
>> the scsi-core to queue more cmnds then we can handle on devices with
>> multiple LUNs, limit the qdepth at the scsi-host level instead of
>> per slave to fix this.
>
> Help me understand this bug a bit more. Are you saying that the commit
> you identify is causing the block layer to queue more commands than
> you've set the per-lun limit to? In which case we have a serious
> problem for more than just UAS. Or are you saying that UAS always had
> a global command limit, but it just didn't get set correctly; however,
> it mostly worked until the above commit exposed the problem?
The latter. UAS has always had a global command limit, which so far
was enforced via a shared tag map rather then setting can_queue
correctly. The identified commit removed the usage of a shared
tag map which causes the core to queue more commands *in total*
then the global limit. I've no reason to believe that the core was
exceeding the per-lun limit on a single lun, but for uas exceeding
the limit when counting all queued commands per lun combined is just
as bad, since it really always was a global limit.
This theory is supported by the only bug report for 4.4 being a
(rare) multi-lun uas disk enclosure.
Regards,
Hans
next prev parent reply other threads:[~2016-03-20 13:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-19 8:59 [PATCH] uas: Limit qdepth at the scsi-host level Hans de Goede
2016-03-19 17:06 ` James Bottomley
2016-03-20 13:28 ` Hans de Goede [this message]
2016-03-21 14:36 ` Christoph Hellwig
[not found] ` <1458377952-12567-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-19 15:52 ` Sergei Shtylyov
2016-03-21 14:36 ` Christoph Hellwig
2016-03-21 14:36 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56EEA57A.9050107@redhat.com \
--to=hdegoede@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=kraxel@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.