From: Hannes Reinecke <hare@suse.de>
To: Chandra Seetharaman <sekharan@us.ibm.com>
Cc: michaelc@cs.wisc.edu, linux-scsi@vger.kernel.org,
dm-devel@redhat.com, Benoit_Arthur@emc.com,
Eddie.Williams@steeleye.com
Subject: Re: [PATCH 0/4] scsi_dh: Make scsi_dh_activate asynchronous
Date: Mon, 05 Oct 2009 15:01:15 +0200 [thread overview]
Message-ID: <4AC9EE1B.7030702@suse.de> (raw)
In-Reply-To: <20090930020811.11455.59565.sendpatchset@chandra-ubuntu>
Chandra Seetharaman wrote:
> Hello All,
>
> Currently, device handlers process path activation in series. This leads
> to a lot of time delay when more than 100 luns are involved. For example,
> with lsi rdac 100+ luns take about 12-15 minutes. This was found by Moger
> Babu of LSI.
>
> This time delay can be avoided if we can do the activations asynchronously.
> By making scsi_dh_activate() async, we can give the device handlers an
> oppurtunity to decide on how to send the device activation down the wire
> to make the turn around time faster. They can send the commands
> asynchronously or send them in batches.
>
> I brought up this issue on the mailing list
> (http://marc.info/?l=linux-scsi&m=123888063818755&w=2) and provided a
> set of patch a loooong while back http://marc.info/?l=linux-scsi&m=124088712709821&w=2
>
> This set of patches applies cleanly on 2.6.31 and I tested the rdac handler
> on the same.
>
> Please review and provide comments.
>
> This set of patched adds asynchronous support for rdac, hp, and alua handlers.
>
Hmm. IIRC we added the synchronous mode by request of LSI/IBM, as the RDAC
handler could only support on MODE SELECT command at a time.
If LSI checked this, okay, no objections.
However: The main reason why we're getting flooded with MODE SELECT commands
is that the RDAC handler switches _each LUN_, not the entire controller.
Seeing that the controller simply cannot cope with the resulting MODE SELECT
flood wouldn't it be more sensible to switch the entire controller here?
After all, we're trying to address a communication failure between the
HBA and the controller, not a failure between the controller and the LUN.
And by that reasoning switching individual LUNs is quite pointless as we
have to switch _all_ LUNs handled by this controller eventually.
So I would suggest to first issue a MODE SENSE command to check which LUNs
are currently handled by this controller and then switch those LUNs in
one go. This way we would be sending quite a few MODE SENSE commands,
but I was under the impression that those do not have any restriction.
I will see to draw up a patch.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
next prev parent reply other threads:[~2009-10-05 13:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-30 2:08 [PATCH 0/4] scsi_dh: Make scsi_dh_activate asynchronous Chandra Seetharaman
2009-09-30 2:08 ` [PATCH 1/4] scsi_dh: Change the scsidh_activate interface to be asynchronous Chandra Seetharaman
2009-10-02 22:04 ` Moger, Babu
2009-10-02 22:36 ` Chandra Seetharaman
2009-10-02 23:02 ` Moger, Babu
2009-09-30 2:08 ` [PATCH 2/4] scsi_dh: rdac handler: Make rdac hardware handler async Chandra Seetharaman
2009-10-02 0:03 ` Moger, Babu
2009-10-02 0:29 ` Chandra Seetharaman
2009-09-30 2:08 ` [PATCH 3/4] scsi_dh: rdac handler: Make hp " Chandra Seetharaman
2009-09-30 2:08 ` [PATCH 4/4] scsi_dh: rdac handler: Make alua " Chandra Seetharaman
2009-10-01 4:19 ` [PATCH 0/4] scsi_dh: Make scsi_dh_activate asynchronous Moger, Babu
2009-10-01 20:54 ` Chandra Seetharaman
2009-10-05 13:01 ` Hannes Reinecke [this message]
2009-10-05 14:35 ` Hannes Reinecke
2009-10-05 23:25 ` Chandra Seetharaman
2009-10-06 8:08 ` Hannes Reinecke
2009-10-06 19:46 ` Moger, Babu
2009-10-07 23:08 ` Moger, Babu
2009-10-09 9:44 ` Hannes Reinecke
2009-10-09 14:06 ` Moger, Babu
2009-10-09 14:55 ` Hannes Reinecke
-- strict thread matches above, loose matches on Subject: below --
2009-10-21 16:22 Chandra Seetharaman
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=4AC9EE1B.7030702@suse.de \
--to=hare@suse.de \
--cc=Benoit_Arthur@emc.com \
--cc=Eddie.Williams@steeleye.com \
--cc=dm-devel@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
--cc=sekharan@us.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).