All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@linux.intel.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-scsi@vger.kernel.org, DL-MPTFusionLinux@lsi.com
Subject: Re: [PATCH 1/2] mpt2sas: Remove acquisition of host_lock
Date: Thu, 7 Apr 2011 01:30:58 -0400	[thread overview]
Message-ID: <20110407053058.GC4673@linux.intel.com> (raw)
In-Reply-To: <20110406134555.GA21729@infradead.org>

On Wed, Apr 06, 2011 at 09:45:55AM -0400, Christoph Hellwig wrote:
> On Tue, Apr 05, 2011 at 05:43:55PM -0400, Matthew Wilcox wrote:
> > 
> > We can eliminate the use of the scsi command serial_number, as the race
> > that the driver is checking for cannot happen.
> > 
> > Then the driver no longer needs to use the DEF_SCSI_QCMD() macro and no
> > longer acquires the host_lock.  This improves performance substantially
> > on high-IOPS workloads.
> 
> Looks fine.  Note that this somehow clashes with my patch to simply
> remove the serial_number check from mpt2sas.  We could just drop my
> smaller patch if this one gets in in a timely fashion.

We should probably split this patch apart into the serial_number removal
and then the host_lock removal anyway.

But I don't think your patch is correct:

-               if (scmd_lookup && (scmd_lookup->serial_number ==
-                   scmd->serial_number))
+               if (scmd_lookup)
                        rc = FAILED;
                else
                        rc = SUCCESS;

The second part of the conditional is always false (right?  because that
command can't be in flight).

So that's (scmd_lookup && 0), which is if (0), so we can just state rc
= SUCCESS.  Or is my reasoning faulty somewhere?

  reply	other threads:[~2011-04-07  5:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05 21:43 [PATCH 1/2] mpt2sas: Remove acquisition of host_lock Matthew Wilcox
2011-04-06 13:45 ` Christoph Hellwig
2011-04-07  5:30   ` Matthew Wilcox [this message]
2011-04-10 22:01     ` Moore, Eric

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=20110407053058.GC4673@linux.intel.com \
    --to=willy@linux.intel.com \
    --cc=DL-MPTFusionLinux@lsi.com \
    --cc=hch@infradead.org \
    --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 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.