From: Christoph Hellwig <hch@infradead.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
james.bottomley@suse.de, dave.jiang@intel.com,
linux-scsi@vger.kernel.org, jacek.danecki@intel.com,
ed.ciechanowski@intel.com, jeffrey.d.skirvin@intel.com,
edmund.nadolski@intel.com
Subject: Re: [RFC PATCH 4/6] isci: hardware / topology event handling
Date: Fri, 25 Mar 2011 15:45:30 -0400 [thread overview]
Message-ID: <20110325194530.GA593@infradead.org> (raw)
In-Reply-To: <AANLkTik7DUF=Pim3JMjRmhdVJTCgfimiyhQ5x_CZ9BeU@mail.gmail.com>
On Thu, Mar 24, 2011 at 05:57:17PM -0700, Dan Williams wrote:
> I have been waiting for this issue to be raised. This was one of the
> first items brought up in our internal reviews of the Linux driver.
> Why does it still exist and what is the rationale for addressing it
> incrementally?:
>
> Starting with simple locking and then scaling it is arguably easier
> than unwinding a more complex locking scheme implemented too early in
> the design phase.
I don't care about the lock scalability. The problem with a global
spinlock is that a lot of primitives that a driver needs need to block,
and with a global spinlock that's almost impossible to handle, as
you'd need to drop the lock, and have very little chance to figure
out what state it actually protects that now needs to be re-checked.
Things are a little better with a global sleeping lock as it allows
you to block, as long as you don't actually plan to keep it over I/O.
next prev parent reply other threads:[~2011-03-25 19:45 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-07 0:34 [RFC PATCH 0/6] isci: initial driver release (part1: intro and lldd) Dan Williams
2011-02-07 0:34 ` [RFC PATCH 1/6] isci: initialization Dan Williams
2011-02-17 8:22 ` Jeff Garzik
2011-02-19 0:12 ` Dan Williams
2011-02-17 8:25 ` Christoph Hellwig
2011-02-19 0:23 ` Dan Williams
2011-03-04 23:35 ` James Bottomley
2011-03-08 1:51 ` Dan Williams
2011-03-18 16:51 ` Christoph Hellwig
2011-02-07 0:34 ` [RFC PATCH 2/6] isci: task (libsas interface support) Dan Williams
2011-02-09 15:01 ` David Milburn
2011-02-14 7:14 ` Dan Williams
2011-02-16 18:48 ` David Milburn
2011-02-16 19:35 ` David Milburn
2011-02-07 0:34 ` [RFC PATCH 3/6] isci: request (core request infrastructure) Dan Williams
2011-03-18 16:41 ` Christoph Hellwig
2011-02-07 0:34 ` [RFC PATCH 4/6] isci: hardware / topology event handling Dan Williams
2011-03-18 16:18 ` Christoph Hellwig
2011-03-23 8:15 ` Dan Williams
2011-03-23 8:40 ` Christoph Hellwig
2011-03-23 9:04 ` Dan Williams
2011-03-23 9:08 ` Christoph Hellwig
2011-03-24 0:07 ` Dan Williams
2011-03-24 6:26 ` Christoph Hellwig
2011-03-25 0:57 ` Dan Williams
2011-03-25 19:45 ` Christoph Hellwig [this message]
2011-03-25 21:39 ` Dan Williams
2011-03-25 22:07 ` Christoph Hellwig
2011-03-25 22:34 ` Dan Williams
2011-03-27 22:28 ` Christoph Hellwig
2011-03-29 1:11 ` Dan Williams
2011-03-30 0:37 ` Dan Williams
2011-02-07 0:35 ` [RFC PATCH 5/6] isci: phy, port, and remote device Dan Williams
2011-02-07 0:35 ` [RFC PATCH 6/6] isci: sata support and phy settings via request_firmware() Dan Williams
2011-02-07 7:58 ` [RFC PATCH 1/6] isci: initialization jack_wang
2011-02-14 7:49 ` Dan Williams
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=20110325194530.GA593@infradead.org \
--to=hch@infradead.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=ed.ciechanowski@intel.com \
--cc=edmund.nadolski@intel.com \
--cc=jacek.danecki@intel.com \
--cc=james.bottomley@suse.de \
--cc=jeffrey.d.skirvin@intel.com \
--cc=linux-scsi@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 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).