Re: Toward runtime power management in Linux

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

[-- Attachment #1: Type: text/plain, Size: 2245 bytes --]


> RTPM core: The scheme described above doesn't necessarily involve the
> PM core.  The notifications can be simple subroutine calls, perhaps
> with support from the bus subsystem.  It's not obvious how much core
> support we will need for RTPM, apart from the sysfs interface.
> 
> Recursion: A consequence of doing things this way is that the
> notifications can potentially use a lot of stack space as they
> progress up the device tree.  (I can't think of any simple
> non-recursive technique for implementing the scheme.)  Fortunately
> this probably won't be too bad; the notifications will stop when they
> reach a device that doesn't want to change its state (because it has
> other children).  So the recursion should not involve too many levels.
> Still, it is something to watch out for.

I think the locking is unmanageable if we do synchronous notification. I
think devices should issue a "request for link state change" and be
asynchronously notified of the actual change, though they might be
allowed to block if they are doing that from process and/or probe()
context (most of the time). I think the actual tree walking should be
done by a separate thread. That simplifies locking tremendously by
suppressing most deadlock conditions.

Another problem is the whole racyness of tree & list walking vs.
add/remove. We try to work around it in various ways that I think can't
work. See the small thread about pci_walk_bus() on lkml that exposes
that kind of races vs. device removal. I think we really need to
indroduce proper iterator objects that get notified on removal.

Racing with device addition is a different issue altogether. It means we
may add devices to already-walked part of the tree, thus have
inconsistent states... unless drivers are made properly aware that the
link state may not be full-on at probe time and deal with that.

> Context: A relatively recent change to the driver model core added a
> semaphore to struct device, and we will want to hold this semaphore
> while making state changes.  This immediately implies that RTPM needs
> a process context to run in.  Should we have a kernel thread or work
> queue specially devoted to RTPM activities (idle autosuspend and so
> forth)?

Might help.

Ben.



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]