From: Benjamin Block <bblock@linux.ibm.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>,
linux-scsi@vger.kernel.org, Ming Lei <ming.lei@redhat.com>,
Mike Christie <michael.christie@oracle.com>,
John Garry <john.g.garry@oracle.com>,
Damien Le Moal <damien.lemoal@opensource.wdc.com>,
Hannes Reinecke <hare@suse.de>,
"James E.J. Bottomley" <jejb@linux.ibm.com>
Subject: Re: [PATCH] scsi: core: Simplify the code for waking up the error handler
Date: Fri, 10 Mar 2023 12:30:34 +0000 [thread overview]
Message-ID: <20230310123034.GF620522@t480-pf1aa2c2.fritz.box> (raw)
In-Reply-To: <53e12a05-f485-f24c-0887-35900c2307c0@acm.org>
On Thu, Mar 09, 2023 at 09:20:45AM -0800, Bart Van Assche wrote:
> On 3/9/23 04:13, Benjamin Block wrote:
> > On Tue, Mar 07, 2023 at 01:51:51PM -0800, Bart Van Assche wrote:
> >> scsi_dec_host_busy() is called from the hot path and hence must not
> >> obtain the host lock if no commands have failed. scsi_dec_host_busy()
> >> tests three different variables of which at least two are set if a
> >> command failed. Commit 3bd6f43f5cb3 ("scsi: core: Ensure that the
> >> SCSI error handler gets woken up") introduced a call_rcu() call to
> >> ensure that all tasks observe the host state change before the
> >> host_failed change. Simplify the approach for guaranteeing that the host
> >> state and host_failed/host_eh_scheduled changes are observed in order by using
> >> smp_store_release() to update host_failed or host_eh_scheduled after
> >> having update the host state and smp_load_acquire() before reading the
> >> host state.
> >
> > It's probably just me, but "simplify" is a bit of a misnomer when you
> > replace RCU by plain memory barriers. And I'm kind of wondering what we
> > improve here? It seems to me that at least as far as the hot path is
> > concerned, nothing really changes? The situation for
> > `scsi_eh_scmd_add()` seems to improve, but that is already way off the
> > hot path.
>
> Hi Benjamin,
>
> The advantages of the approach introduced by this patch are as follows:
> * The size of struct scsi_cmnd is reduced. This may improve performance
> by reducing the number of cache misses.
> * One call_rcu() call is eliminated. This reduces the error handler
> wake-up latency.
Is that really a problem today? From personal experience we hardly ever
have any real SCSI timeouts in our environments, and once we are at the
point where we add commands to EH, we are already past the (default) 30s
timeout for disks IIRC, so is the RCU latency significant at that point?
I'm just wondering, because at least IMHO plain memory barrier are more
complex than RCU - at least in understanding them.
--
Best Regards, Benjamin Block / Linux on IBM Z Kernel Development / IBM Systems
IBM Deutschland Research & Development GmbH / https://www.ibm.com/privacy
Vorsitz. AufsR.: Gregor Pillen / Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294
prev parent reply other threads:[~2023-03-10 12:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-07 21:51 [PATCH] scsi: core: Simplify the code for waking up the error handler Bart Van Assche
2023-03-09 12:13 ` Benjamin Block
2023-03-09 17:20 ` Bart Van Assche
2023-03-10 12:30 ` Benjamin Block [this message]
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=20230310123034.GF620522@t480-pf1aa2c2.fritz.box \
--to=bblock@linux.ibm.com \
--cc=bvanassche@acm.org \
--cc=damien.lemoal@opensource.wdc.com \
--cc=hare@suse.de \
--cc=jejb@linux.ibm.com \
--cc=john.g.garry@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=michael.christie@oracle.com \
--cc=ming.lei@redhat.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