[Ksummit-discuss] [TECH TOPIC] Device power management during system-wide PM transitions

Rafael J. Wysocki rjw at rjwysocki.net
Sat Oct 21 23:41:00 UTC 2017


On Saturday, October 21, 2017 8:51:41 PM CEST Bart Van Assche wrote:
> On Wed, 2017-10-18 at 13:17 +0200, Rafael J. Wysocki wrote:
> > If this isn't too late, I'd like to put a PM topic on the agenda.
> > 
> > One problem basically is that runtime PM interacts with system-wide PM for
> > devices in ways that need to be taken care of.  The most common patterns are:
> > 
> > - What if a device is in runtime suspend before system suspend?  Can it
> >   remain suspended and under what conditions if so?
> > 
> > - Can devices be left in suspend when the system is resuming from
> >   system-wide suspend?
> > 
> > - Can driver runtime PM callbacks be used for system-wide PM too and to
> >   what extent?  If they can, how to make that happen?
> > 
> > We have tried to address these points in a couple of different ways so
> > far, but none of them is universal enough.  Moreover, one approach is
> > mostly for systems with PCI/ACPI and the other one is used on systems
> > without those and they both are not compatible.  That sort of didn't
> > matter until IP block sharing between vendors led to situations in
> > which one and the same driver is expected to work in both environments.
> > 
> > It would be good to have a common approach and IMO it should be based on
> > changing the PM core to help address the most common cases, so I posted
> > a set of patches to that end:
> > 
> > https://marc.info/?l=linux-kernel&m=150811822405206&w=2
> > 
> > and I'd like to have a discussion regarding that and it spans many
> > different subsystems potentially, so the KS seems to be the right venue
> > for that discussion to happen.
> > 
> > The second issue is that some bus types and quite a few drivers still use
> > legacy power management callbacks and I'd like to get rid of those at last,
> > first from the bus types and then from drivers too.  That's more of a
> > heads-up thing, but also possibly touches multiple places, so should be
> > suitable for a KS session as well.
> 
> Hello Rafael,
> 
> How about adding orderly freezing of the storage stack to the list of items
> to discuss?

Do you mean add it to the agenda?

We can do that I think, but then I'm not sure how much time we'll be able to
spend on it.

> Some people use the md RAID1 driver on their laptop and run a
> filesystem on top of the md RAID1 driver. Both the XFS filesystem and the md
> RAID1 driver create kernel threads. Freezing of kernel threads does not yet
> happen in a top-down order compared to the order in which storage drivers
> and filesystems have been stacked. Do you think this should be discussed
> during the KS time slot about PM?

Well, it should be discussed and the PM session would be a good opportunity
for at least some discussio about that to happen IMO.

> For a related discussion, see also Luis R. Rodriguez, [RFC 0/5] fs: replace
> kthread freezing with filesystem freeze/thaw, 3 October 2017
> (https://lkml.org/lkml/2017/10/3/821).

Yup.

Thanks,
Rafael



More information about the Ksummit-discuss mailing list