[linux-pm] Nested suspends; messages vs. states

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 22 Mar 2005, Patrick Mochel wrote:

> On Tue, 22 Mar 2005, Alan Stern wrote:
> 
> > When per-device locking gets added to the driver model, this can be
> > handled by making the PM core lock all devices before starting STR and
> > unlock them all after waking up.  Then any user process trying to resume a
> > device in the middle will block until the system is fully awake.
> 
> That's not a sane design. You do not want 1 function locking and another
> unlocking. That's trouble waiting to happen. We can solve that problem
> today using a single semaphore to synchronize all PM calls. If a runtime
> PM request comes in while a system PM request is being processed, that
> process will block until the semaphore is dropped (when the system is
> resumed). It will serialize all runtime PM calls, but those are not
> performance-critical operations, and it shouldn't matter too much.

1 function locking and another unlocking?  Not being aware of all the
details of the system-power-management code, I kind of assumed STR looked
something like this:

	void suspend_to_ram()
	{
		suspend all devices
		turn off main power
		/* Zzzz... */
		resume all devices
	}

So what's wrong with changing it into:

	void suspend_to_ram()
	{
		lock all devices
		suspend all devices
		turn off main power
		/* Zzzz... */
		resume all devices
		unlock all devices
	}

I agree that your single-semaphore idea would also work to prevent 
unwanted resumes during a system sleep.  But it doesn't protect against 
the possibility of devices being removed or added while the PM core is 
traversing its lists.  Locking does protect against that -- or rather, it 
will once the mechanisms have been added to the driver model core.

Now maybe the list traversal doesn't need protection.  Something like 
"Always suspend next the most recently added device that hasn't already 
been suspended" would probably work okay.  But given that during a system 
sleep transition the PM core is supposed to be in control of all devices 
for the entire time they are suspended, doesn't it make sense to have it 
lock them?

Alan Stern


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux