From: James Bottomley <James.Bottomley@suse.de>
To: Tejun Heo <tj@kernel.org>
Cc: Linux SCSI List <linux-scsi@vger.kernel.org>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] scsi: don't use execute_in_process_context()
Date: Sun, 12 Dec 2010 16:48:33 -0600 [thread overview]
Message-ID: <1292194113.2989.9.camel@mulgrave.site> (raw)
In-Reply-To: <4CBD95DC.8000001@kernel.org>
On Tue, 2010-10-19 at 14:58 +0200, Tejun Heo wrote:
> SCSI is the only subsystem which uses execute_in_process_context().
> With the recent workqueue updates, unconditionally using work wouldn't
> cause deadlocks around execution resources and the two places where
> SCSI uses them are cold paths where using work unconditionally
> wouldn't make any difference. Drop execute_in_process_context() and
> use work directly.
Sorry, managed to lose this until the ping.
The analysis above isn't quite correct, I'm afraid. We use the
execute_in_process_context() not to avoid deadlocks, but to acquire
process context if we don't have it because the API allows calling from
sites at interrupt context. The point of using
execute_in_process_context() is that we actually want to make use of the
user context if we have one ... there's no point using a workqueue in
that case, because there's nothing to be gained (except to slow
everything down). We have no ordering constraints (the traditional
reason for using workqueues) so this is purely about context.
Alan stern recently did an analysis (at least for the target reap) that
says we actually have no interrupt context call sites, so abandoning the
execute_in_process_context() for a direct call in that case might make
sense.
James
next prev parent reply other threads:[~2010-12-12 22:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-19 12:57 [PATCH 1/2] scsi: remove bogus use of struct execute_work in sg Tejun Heo
2010-10-19 12:58 ` [PATCH 2/2] scsi: don't use execute_in_process_context() Tejun Heo
2010-10-22 10:03 ` FUJITA Tomonori
2010-12-12 22:48 ` James Bottomley [this message]
2010-12-14 9:53 ` Tejun Heo
2010-12-14 14:09 ` James Bottomley
2010-12-14 14:19 ` Tejun Heo
2010-12-14 14:26 ` James Bottomley
2010-12-14 14:33 ` Tejun Heo
2010-12-15 3:04 ` James Bottomley
2010-12-15 15:47 ` Tejun Heo
2010-12-15 15:54 ` James Bottomley
2010-12-15 16:00 ` Tejun Heo
2010-12-15 17:22 ` James Bottomley
2010-12-15 19:05 ` Tejun Heo
2010-12-15 19:10 ` James Bottomley
2010-12-15 19:19 ` Tejun Heo
2010-12-15 19:33 ` James Bottomley
2010-12-15 19:42 ` Tejun Heo
2010-12-15 19:46 ` Tejun Heo
2010-12-16 14:39 ` James Bottomley
2010-12-16 15:51 ` Tejun Heo
2010-12-15 19:34 ` Tejun Heo
2010-10-20 14:29 ` [PATCH 1/2] scsi: remove bogus use of struct execute_work in sg FUJITA Tomonori
2010-10-20 19:56 ` Douglas Gilbert
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=1292194113.2989.9.camel@mulgrave.site \
--to=james.bottomley@suse.de \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=tj@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
all inboxes | Powered by JetHome®