From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Huang Ying" <ying.huang@intel.com>, "Bjørn Mork" <bjorn@mork.no>,
"huang ying" <huang.ying.caritas@gmail.com>,
"Zheng Yan" <zheng.z.yan@intel.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-usb@vger.kernel.org,
"Linux PM list" <linux-pm@vger.kernel.org>
Subject: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)
Date: Tue, 31 Jul 2012 22:31:19 +0200 [thread overview]
Message-ID: <201207312231.19505.rjw@sisk.pl> (raw)
In-Reply-To: <201207292118.42547.rjw@sisk.pl>
On Sunday, July 29, 2012, Rafael J. Wysocki wrote:
> On Sunday, July 29, 2012, Alan Stern wrote:
> > On Sun, 29 Jul 2012, Rafael J. Wysocki wrote:
> >
> > > The difference is, if you use _put_sync(), you need to wait the extra 10 ms
> > > for local_pci_probe() to return (if the parent is actually suspended),
> > > although you might not need to wait for it if you used _put(), right?
> >
> > Yes, that's the difference. But who waits for local_pci_probe() to
> > return? :-)
>
> pci_register_driver() might, but that's not a big deal. Hot-plug might
> as well, though.
>
> > > Which, to me, means that using _put_sync() may not be always better.
> > > It probably doesn't matter a lot, but then the workqueue overhead shouldn't
> > > matter a lot either.
> >
> > It's that in the end, the extra overhead is pretty small. For me
> > there's also an issue of style: If you do a synchronous get then it
> > looks odd not to do a synchronous put. My feeling has always been that
> > the async routines are for use in non-process contexts, where the sync
> > routines can't be used. Using them just to return a little more
> > quickly is a foreign idea.
>
> I see. :-)
>
> The reason for using sync get is quite obvious: we want to be able to access
> the device later on. For sync put that's not so clear, though. There are cases
> when we definitely want to do it, like the failing .probe() in which we want to
> disable runtime PM next to the put, but usually it doesn't hurt (too much) to
> defer it IMO.
Now it occured to me that perhaps we don't need the current asynchronous
pm_runtime_get() at all. The usefulness of it is quite questionable, because
either we want to resume the device immediately, for which pm_runtime_get_sync()
should be used, or we just want to bump up the usage counter, in which cases
pm_runtime_get_noresume() should always be sufficient. I fail to see any
particularly compelling use case for pm_runtime_get() doing an asynchronous
resume at the moment, but perhaps that's just me.
However, I receive reports of people using pm_runtime_get() where they really
should use pm_runtime_get_sync(), so I wonder if we can simply rename
pm_runtime_get_sync() as pm_runtime_get() and drop the asynchronous version
altogether?
Rafael
next prev parent reply other threads:[~2012-07-31 20:25 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44L0.1207241312050.1164-100000@iolanthe.rowland.org>
[not found] ` <87r4s0opck.fsf@nemi.mork.no>
2012-07-25 4:08 ` bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure Bjørn Mork
2012-07-25 4:34 ` Huang Ying
2012-07-25 9:58 ` Bjørn Mork
2012-07-25 13:30 ` huang ying
2012-07-25 13:58 ` Bjørn Mork
2012-07-25 18:56 ` Rafael J. Wysocki
2012-07-25 20:02 ` Rafael J. Wysocki
2012-07-25 22:36 ` Bjørn Mork
2012-07-26 2:38 ` Huang Ying
2012-07-26 2:38 ` Huang Ying
2012-07-26 8:54 ` Huang Ying
2012-07-26 10:35 ` Bjørn Mork
2012-07-26 11:02 ` Bjørn Mork
2012-07-26 12:04 ` Bjørn Mork
2012-07-26 15:03 ` Alan Stern
2012-07-26 16:24 ` Bjørn Mork
2012-07-27 5:35 ` Huang Ying
2012-07-27 9:11 ` Bjørn Mork
2012-07-30 3:15 ` Huang Ying
2012-07-30 8:08 ` Bjørn Mork
2012-07-30 13:31 ` huang ying
2012-07-30 16:57 ` Bjørn Mork
2012-07-31 0:22 ` Huang Ying
2012-07-30 14:19 ` Alan Stern
2012-07-31 0:24 ` Huang Ying
2012-07-31 3:18 ` Huang Ying
2012-07-31 17:07 ` Alan Stern
2012-07-27 15:03 ` Alan Stern
2012-07-27 19:11 ` Rafael J. Wysocki
2012-07-27 19:39 ` Alan Stern
2012-07-27 19:54 ` Rafael J. Wysocki
2012-07-28 16:12 ` Alan Stern
2012-07-28 20:26 ` Rafael J. Wysocki
2012-07-28 21:12 ` Alan Stern
2012-07-29 13:55 ` Rafael J. Wysocki
2012-07-29 14:55 ` Alan Stern
2012-07-29 19:18 ` Rafael J. Wysocki
2012-07-31 20:31 ` Rafael J. Wysocki [this message]
2012-07-31 21:05 ` Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...) Alan Stern
2012-07-31 21:34 ` Rafael J. Wysocki
2012-07-31 21:49 ` Rafael J. Wysocki
2012-08-01 14:36 ` Alan Stern
2012-08-01 21:24 ` Rafael J. Wysocki
2012-08-02 20:16 ` Alan Stern
2012-08-02 21:26 ` Rafael J. Wysocki
2012-08-03 2:20 ` Alan Stern
2012-08-03 3:37 ` Ming Lei
2012-08-03 14:28 ` Alan Stern
2012-08-04 19:47 ` Rafael J. Wysocki
2012-08-04 20:25 ` Alan Stern
2012-08-04 20:48 ` Rafael J. Wysocki
2012-08-04 20:48 ` Alan Stern
2012-08-04 21:15 ` Rafael J. Wysocki
2012-08-04 22:13 ` Alan Stern
2012-08-05 15:26 ` Rafael J. Wysocki
2012-08-06 13:30 ` Ming Lei
2012-08-06 14:47 ` Alan Stern
2012-08-07 1:35 ` Ming Lei
2012-08-07 11:23 ` Rafael J. Wysocki
2012-08-07 15:14 ` Ming Lei
2012-08-07 15:42 ` Alan Stern
2012-08-07 16:30 ` Ming Lei
2012-08-07 20:57 ` Rafael J. Wysocki
2012-08-07 20:45 ` Rafael J. Wysocki
2012-08-08 2:02 ` Ming Lei
2012-08-08 18:42 ` Alan Stern
2012-08-08 20:16 ` Rafael J. Wysocki
2012-08-09 5:55 ` Ming Lei
2012-08-09 10:46 ` Rafael J. Wysocki
2012-08-09 10:55 ` Ming Lei
2012-08-09 19:41 ` Rafael J. Wysocki
2012-08-10 3:19 ` Ming Lei
2012-08-10 20:29 ` Rafael J. Wysocki
2012-08-08 22:27 ` Rafael J. Wysocki
2012-08-06 15:48 ` Alan Stern
2012-08-06 20:30 ` Rafael J. Wysocki
2012-08-07 12:28 ` Rafael J. Wysocki
2012-08-07 17:15 ` Alan Stern
2012-08-07 21:31 ` Rafael J. Wysocki
2012-08-03 14:05 ` Alan Stern
2012-08-04 20:08 ` Rafael J. Wysocki
2012-08-04 20:42 ` Alan Stern
2012-08-04 20:59 ` Rafael J. Wysocki
2012-08-04 19:35 ` Rafael J. Wysocki
2012-07-29 20:12 ` bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure Jassi Brar
2012-07-29 21:44 ` Alan Stern
2012-07-25 19:51 ` [PATCH] PCI / PM: Fix messages printed by acpi_pci_set_power_state() Rafael J. Wysocki
2012-07-25 20:02 ` Alan Stern
2012-07-25 20:48 ` [PATCH][update] " Rafael J. Wysocki
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=201207312231.19505.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=bhelgaas@google.com \
--cc=bjorn@mork.no \
--cc=huang.ying.caritas@gmail.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=ying.huang@intel.com \
--cc=zheng.z.yan@intel.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;
as well as URLs for NNTP newsgroup(s).