From: Doug Ledford <dledford@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Luben Tuikov <luben_tuikov@adaptec.com>,
Arjan Van de Ven <arjanv@redhat.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH]: Flexible timeout infrastructure
Date: Tue, 15 Jun 2004 12:24:01 -0400 [thread overview]
Message-ID: <1087316640.3556.147.camel@compaq.xsintricity.com> (raw)
In-Reply-To: <20040615155716.GA14017@infradead.org>
On Tue, 2004-06-15 at 11:57, Christoph Hellwig wrote:
> On Tue, Jun 15, 2004 at 11:48:45AM -0400, Luben Tuikov wrote:
> > This really isn't anything new or paramount. It's just a simple
> > extension, marked OPTIONAL, that only *capable* drivers should use.
> > (i.e. the aic7xxx drivers, maybe some FC and USB).
> >
> > So it's not really that big of a deal, but does wonders to
> > SCSI Core in terms of recovery time and *uninterruptible*
> > IO.
>
> Well, the question is always what is so special about your driver that
> it doesn't benefit from beeing in a common library.
Well, pretty much the fact that the hardware determines what level of
recovery is possible, not the transport. Even between different SPI
hardware, aka aic7xxx vs. sym53c8xx, you have different levels of
ability to perform recovery as dictated by how much of the adapter's
operation is handled by firmware you can control and how much isn't.
Thinking that you can make a single SPI class recovery thread that's
actually elegant in relation to the particular hardware is wrong. The
*only* place that will ever be able to do elegant error recovery is the
hardware driver. It's the only code with the knowledge to be able to
discern a stuck device from a stuck bus from a missing transport from a
hung host, etc. You can make a so-so generic layer if you want, like we
have now, but that shouldn't be a reason to stop a good driver from
doing the right thing if it wants to. And that's what Luben's patch
does. It doesn't force *any* driver to write any new eh code, it only
*allows* a driver to do so, and to fall back on the generic code if it
wants. That would actually solve a lot of the reasons that drivers
currently do things like kill the timer on commands and set their own
timer on the command internally, stuff like that. To me, the ability to
tell the eh thread to chill out, this command doesn't really have a
problem (and in my experience, the first command to timeout is not the
problem command 95% of the time) is a major benefit.
> I've pulled more crap
> out of individual drivers than I'd ever want to imagine, and because of
> that I'm pretty much allergic against giving driver writers more control
> then nessecary.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
next prev parent reply other threads:[~2004-06-15 16:24 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-15 15:02 [PATCH]: Flexible timeout infrastructure Luben Tuikov
2004-06-15 15:08 ` Signed-off-by: added [Re: [PATCH]: Flexible timeout infrastructure] Luben Tuikov
2004-06-15 15:24 ` Matthew Wilcox
2004-06-15 15:27 ` [PATCH]: Flexible timeout infrastructure Arjan van de Ven
2004-06-15 15:40 ` Luben Tuikov
2004-06-15 15:42 ` Christoph Hellwig
2004-06-15 15:46 ` Luben Tuikov
2004-06-15 15:49 ` Christoph Hellwig
2004-06-15 15:43 ` Arjan van de Ven
2004-06-15 15:48 ` Luben Tuikov
2004-06-15 15:57 ` Christoph Hellwig
2004-06-15 16:07 ` Arjan van de Ven
2004-06-15 16:24 ` Doug Ledford [this message]
2004-06-15 16:27 ` Luben Tuikov
2004-06-15 16:33 ` Arjan van de Ven
2004-06-15 18:07 ` Luben Tuikov
2004-06-15 15:31 ` James Bottomley
2004-06-15 18:15 ` Mike Anderson
2004-06-15 18:37 ` Luben Tuikov
2004-06-15 19:20 ` Mike Anderson
2004-06-15 19:52 ` Luben Tuikov
2004-06-15 20:57 ` Mike Anderson
2004-06-15 22:00 ` Luben Tuikov
2004-06-15 22:31 ` Luben Tuikov
2004-06-15 22:13 ` Doug Ledford
2004-06-15 19:12 ` Luben Tuikov
2004-06-15 19:54 ` James Bottomley
2004-06-16 15:27 ` Mike Anderson
2004-06-16 15:37 ` James Bottomley
2004-06-16 15:48 ` Luben Tuikov
2004-06-16 15:58 ` James Bottomley
-- strict thread matches above, loose matches on Subject: below --
2004-06-16 16:58 Smart, James
2004-06-16 17:04 ` James Bottomley
2004-06-16 18:58 ` Luben Tuikov
2004-06-16 19:17 ` James Bottomley
2004-06-16 17:10 Smart, James
2004-06-16 17:21 ` James Bottomley
2004-06-16 17:33 Smart, James
2004-06-16 17:38 ` James Bottomley
2004-06-16 18:05 Smart, James
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=1087316640.3556.147.camel@compaq.xsintricity.com \
--to=dledford@redhat.com \
--cc=arjanv@redhat.com \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=luben_tuikov@adaptec.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