lkml.org 
[lkml]   [2010]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2
[CC: list trimmed drastically, on the assumption that most of the 
people on it aren't very interested in the details of the PM runtime
memory barriers.]

On Wed, 27 Oct 2010, Mathieu Desnoyers wrote:

> grep -r pm_runtime_get_noresume drivers/ hands out very interesting info.
>
> e.g.:
>
> drivers/usb/core/drivers.c: usb_autopm_get_interface_async()
>
> pm_runtime_get_noresume(&intf->dev);
> s = ACCESS_ONCE(intf->dev.power.runtime_status);
> if (s == RPM_SUSPENDING || s == RPM_SUSPENDED)
> status = pm_request_resume(&intf->dev);
>
> How is this supposed to work ?

It's worth pointing out that this code is going to be removed during
the 2.6.38 development cycle, due to ongoing changes in the runtime PM
core. It would have been removed already if not for the difficulty of
coordinating cross-subsystem changes.

But it's legitimate to ask how the code _was_ supposed to work...

> If the ACCESS_ONCE can be reordered before the atomic_inc(), then I fear the
> device can be suspended even after the check.

You are correct; the code as written may sometimes fail. It was a
hack from the beginning; the kind of test it performs should not be
done outside the PM core. However at the time it was the easiest way
to do what I wanted.

> My point is that a get/put semantic should imply memory barriers, especially if
> these are exported APIs.

As far as I am aware, apart from the hack above,
pm_runtime_get_noresume is called only in places where either:

it is purely advisory (e.g., we know that we will use the
device in the near future so we would prefer to prevent it from
being suspended, but we don't really care because we're going
to call pm_runtime_resume_sync before using it anyway);

or we already know that the usage_count is > 0.

No memory barrier is required for either of these cases.

Alan Stern



\
 
 \ /
  Last update: 2010-10-27 16:35    [W:0.044 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site