LKML Archive on
help / color / mirror / Atom feed
From: "Patro, Sumant" <>
To: "James Bottomley" <>
Cc: <>, <>,
	"Kolli, Neela" <>,
	"Yang, Bo" <>
Subject: RE: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy
Date: Fri, 16 Feb 2007 17:50:11 -0700	[thread overview]
Message-ID: <> (raw)

Hello James,

	It is difficult to know when the device will go into a state
where it is not able to process cmds within timeout period consistently.
Many factors may be contributing for the device to get into this state. 
	Reducing can_queue may help but the difficult part is when does
the can_queue value be restored to the original value. Because, the
device may come back to normal functioning after some time. Also
reducing it to a optimum value that will work for all possible cases is
a challenge.

	In a typical setup the throttle io code may not get executed. It
is required only when it has not been able to complete cmds more than 2
times within timeout period.



-----Original Message-----
From: James Bottomley [] 
Sent: Friday, February 16, 2007 9:51 AM
To: Patro, Sumant
Cc:;;; Kolli, Neela; Yang, Bo
Subject: RE: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy

On Thu, 2007-02-15 at 19:53 -0700, Patro, Sumant wrote:
> Hello James,
> 	I re-submitted the patch yesterday with the "space" issue fixed 
> (adhering to coding guideline).
> 	I will check for alternative to calculate the time driver have
> sending host busy to OS. Will check with time_before() as you have 
> suggested.
> 	Throttling from megasas_generic_reset() handler did not help.
> megaraid does not have feature to abort cmds. So, in the generic reset

> routine, the driver just waits for cmd completion by FW. These 
> timed-out cmds gets retried by mid-layer with "retries" incremented by
> Eventually we see retries equals max_allowed followed by SCSI error 

That's rather what worries me.  When the error handler activates (which
it will on the first timeout), it waits for all commands to complete or
time out before running.  Your reset handler does nothing other than
wait for the firmware to complete the commands (now uselessly), so we
now wait for the entire firmware command queue to drain, then you tell
the mid layer everything is OK, so it loads you up again with all the
commands plus a few test unit readies for good measure, then you

You really want to catch the device going into this condition and do
something at that point ... prime candidate would be lowering the
can_queue depth to get fewer commands transiting the firmware.


             reply	other threads:[~2007-02-17  0:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-17  0:50 Patro, Sumant [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-02-16  2:53 Patro, Sumant
2007-02-16 17:50 ` James Bottomley
2007-02-06 22:11 Sumant Patro
2007-02-16  0:10 ` James Bottomley

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='RE: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).